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WELCOME 


The  National  Computer  Security  Center  and  the  Institute  for  Computer 
Sciences  and  Technology  are  pleased  to  welcome  you  to  the  Tenth  Annual  National 
Computer  Security  Conference.  The  past  nine  conferences  have  stimulated  the 
sharing  of  information  and  the  application  of  this  new  technology.  We  are 
confident  this  year's  conference  will  continue  this  tradition. 

This  year's  conference  theme  —  Computer  Security:  From  Principles  to 
Practices  —  reflects  the  growth  of  computer  security  awareness  and  a  maturation 
of  the  technology  of  trusted  systems.  Our  next  major  challenge  is  to  understand 
how  to  build  secure  applications  on  these  trusted  bases.  The  efforts  of  the 
National  Computer  Security  Center,  the  Institute  for  Computer  Sciences  and 
Technology,  computer  users,  and  the  computer  industry  have  all  contributed  to  the 
advances  in  computer  security  over  the  past  few  years.  IVe  are  committed  to  a 
vibrant  partnership  between  the  Federal  Government  and  private  industry  in 
furthering  the  state  of  the  art  in  Computer  Security. 

The  great  challenge  of  the  future  is  for  us  to  build  upon  the  bases  we  are 
now  developing  so  that  new  applications  can  emerge.  We  must  understand  and 
" record "  how  we  build  on  these  foundations  in  order  to  secure  end  products.  To 
be  successful,  we  need  your  help  as  you  take  back  to  your  places  of  work  a.i 
increased  awareness  of  where  we  arc  and  where  we  must  go. 


/JAMES  H.  BURROWS 
Director 

Institute  for  Computer  Sciences 
and  Technology 
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DEVELOPMENTS  IN  GUIDANCE  FOR  TRUSTED  COMPUTER  NETWORKS 


Alfred  W .  Arsenault 

National  computer  Security  Center 
Ft.  George  G.  Meade,  MD 


Abstract 

The  Technical  Guidelines  Division  of  the  NCSC 
has  been  working  to  produce  guidance  for 
Trusted  Computer  Networks  that  would  be 

analogous  to  thav  provided  for  stand-alone 

computer  systems  by  the  Trusted  Computer 
.system  Evaluation  Criteria.  This  paper 

discusses  the  latest  events  in  that  develop¬ 
ment:  the  Trusted _ Network  Interpretation 

(TNI),  how  tlie  TNI  came  to  be,  what  its 
implications  are,  arid  what  lies  ahead. 

introduction 

The  purpose  of  this  paper  is  to  discuss  the 
current  status  and  future  plans  for  guidance 
in  the  area  of  trusted  computer  networks.  The 
National  Computer  Security  Center  ("the  Cen¬ 
ter")  has  been  working  on  this  problem  since 
late  1903;  earlier  stages  in  the  development 
can  be  seen  in  the  proceedings  of  the  New 
Orleans  Workshop  [1]  and  in  the  draft  Trusted 
Network  Evaluation  Criteria  (2),  or  "Brown 
Book".  In  April  of  1907,  the  Center  distri¬ 
buted  for  review  the  draft  Trusted  Network 
interpretation  [3],  or  "tnx". 

The  Now  Philosophy 

Comments  received  on  the  Brown  Book  led  the 
center  to  believe  that  it  did  not  reflect  the 
right  approach  to  network  security.  There¬ 
fore,  it  was  necessary  to  reexamine  some  of 
the  early  results,  and  to  take  a  different 
approach  to  developing  net  fork  guidance.  This 
new  approach  is  actually  a  marriage  of  some  of 
the  early  recommendations.  It  involves  the 
realization  that,  although  not  all  networks 
can  be  evaluated  and  assigned  a  single  rating, 
some  can.  Specifically,  the  working  group 
responsible  for  producing  ttie  TNI  believes 
that  the  reference  monitor  concepit1  is 
appropriate  for  certain  network  systems. 
These  systems  fit  what  is  called  the  "single 
trusted  system  view"  -  that  is,  they  can 
accurately  be  regarded  as  an  instance  of  a 


single  trusted  system.  Networks  of  this  type 
have  a  single  trusted  computing  base,  referred 
to  as  the  Network  Trusted  Computing  Base 
(NTCB) .  The  NTCB  is  partitioned  among  the 
network  components  in  a  manner  that  ensures 
the  overall  network  security  policy  is 
enforced  by  the  network  as  a  whole. 

The  implication  of  this  is  that  these  networks 
can  be  evaluated,  using  the  concepts  embodied 
in  t.hc  Trusted  Computer  System  F.valuation 
Criteria  [4]  (TCSEC)  as  the  basis  for  the 
evaluation.  The  words  in  the  TCSEC  may  not 
apply  directly;  they  must  be  interpreted  as 
necessary  for  the  network  context.  Addition¬ 
ally,  these  requirements  may  need  to  be 
augmented  by  other  requirements,  such  as  those 
for  "other  security  services"  like  Communi¬ 
cations  Integrity,  Authentication,  Non- 
Repudiation,  and  Assurance  of  service.  How¬ 
ever,  it  is  important  to  realize  that  the 
fundamental  concepts  of  network  evaluations 
are  those  described  in  the  TCSEC;  new  concepts 
are  introduced  only  where  essential  to 
understand  the  TCSEC  in  the  network  context. 

Networks  for  which  no  meaningful  evaluation  is 
possible  are  addressed  using  the  "intercon¬ 
nected  accredited  Automated  Information  System 
(AIS)  view. "2  The  interconnected  accredited 
AIS  view  is  an  operational  perspective  that 
recognizes  that  parts  of  the  network  may  be 
indepenuencly  created,  managed,  and  accre¬ 
dited,  Each  AIS  is  accredited  to  handle 
sensitive  information  at  a  single  level  or 
over  a  range  of  levels.  In  this  view,  the 
individual  AIS  may  be  thought  of  as  "devices" 
with  which  neighboring  components  can  send  and 
receive  information.  An  interconnection  rule 
must  be  enforced  to  limit  the  levels  of 
information  communicated  across  the  network. 

The  difference  between  these  two  views  is 
simple,  and  it  is  a  major  one.  When  a  "single 
trusted  system"  (or  a  component,  as  will  be 
explained  later)  is  evaluated,  the  result  is  a 
technical  statement  about  the  strength  of  the 
system.  This  statement  is  made  (usually) 
without  regard  to  the  specific  environment  in 


ffiy  "reference  monitor  concepv."  we  mean  strictly  the  concept 
of  an  abstract  machine  that  mediates  all  accesses  of  subjects  to 
objects.  We  do  not  mean  tc  imply  "reference  validation 
mechanism",  "security  kernel",  or  even  "Boll  and  LaPadula  model". 

2for  the  purposes  of  this  paper,  an  AIS  is  any  system  which 
is  used  to  create,  piepare,  or  manipulate  information  in 
electronic  form. 

) 


which  the  system  will  be  ope  rated,  and  all 
systems  with  the  same  rating  meet  the  same 
criteria.  No  such  statement  can  be  made  about 
an  "interconnected  accredited  A1S";  all  that 
can  bo  provided  is  technical  guidance  to  an 
accreditor  about  certain  rules  to  follow  in 
hooking  up  components.  The  technical  state¬ 
ment  provided  by  an  evaluation  is  much 
stronger  than  any  interconnect  ion  rule,  and 
leads  to  much  more  confidence  that  the  system 
will  behave  properly  when  it  is  installed. 


Why  is  it.  an  "Interpretation"  ? 

It  is  a  simple  statement  of  fact  that  the 
TCSUC  actually  contains  two  tilings.  First,  it 
contains  the  general  requirements  for  a 
t  lusted  system  ON  ANY  TV  I'll .  Second,  it 
contains  an  interpretation  of  those  require¬ 
ments  for  general-purpose  operating  systems, 
in  some  ways,  it  is  unfortunate  that  these  two 
things  are  so  tightly  interwenved  throughout 
the  document,  but  that  is  the  way  the  document 
was  written.  Since  the  TNI  is  an  interpre¬ 
tation  of  the  general  requirements  for 
networks,  it  is  on.  the  same  level  as  the 
into  r  ”  rot  a  t  i  on  lor  General  *“nurnni.:c 

systems  in  the  'lCSTC.  That  is,  it  is  much 

more  than  a  "Guideline".  However,  the  TNI  is 
an  "Interpretation"  rather  than  a  "Criteria" 
because  it  interprets  the  general  require¬ 
ments,  which  have  already  been  stated  by  the 
TCSbC. 


Structure  of  the  Document 

The  TNI  is  divided  into  two  parts,  plus  three 
appendices.  Tart  I  of  the  document  contains 
the  TCl'.EC  interpretations.  For  each  require¬ 
ment  in  each  class,  the  requirement  is  stated 
as  it.  appears  in  D0D52 00 . 28-STD .  Then,  the 
interpretation  of  the  requirements  is  stated. 
Finally,  rationale  is  provided — an  explanation 
of  why  the  interpretation  is  as  it  is.  For 
some  requirements,  examples  of  acceptable 
mechanisms  are  also  provided. 

l’art  II  contains  the  requirements  for  security 
services  such  as  Communications  Field 
Integrity,  Non-Repudiation,  Continuity  of 
Operations,  and  Network.  Management.  Tart  II 
includes  discussions  of  general  assurance 


1  actors,  documentation  requirements,  and  how 
to  determine  which  services  are  needed  in  a 
particular  application. 

Appendix  A  discusses  the  evaluation  of 
components.  Appendix  II  provides  the  technical 
rationale  behind  the-  partitioned  NTC1' 
approach.  Appendix  c  discusses  considerations 
involved  in  the  Interconnected  Accredited  Air 
view.  There  is  also  a  list  of  acronyms  used 
in  the  document,  and  a  glossary  of  terms. 


Relationship  to  iso  Work. 

An  cllort  is  underway  to  extend  the  ISO  Open 
System  1 ntorconnect i on  (OS1 )  architecture  by 
defining  security-related  architectural 
elements  which  can  be  applied  in  the 
circumstances  lor  which  protection  of 
communications  is  required  [3].  There  is 
considerable  overlap  between  the  OS]  Security 
Addendum  and  Fart  11  of  the  TNI.  Since  at  the 
time  of  this  writing  both  documents  are 
evolving,  it  is  difficult  to  exactly  detino 
the  relationship.  Howevei ,  some  of  the 
security  services  identified  in  the  ISO 
addendum  are  addressed  in  Part  1  of  the  TNI, 
while  ot.hel  s  ale  add !  esstiu  ill  Fait.  II.  The 
piinciplc  difference  is  that  the  ISO  work  is 
primarily  concerned  with  Functionality, 
somewhat  concerned  with  Strength  of  Mechanism, 
and  rarsly  concerned  with  Assurance.  The  TNI, 
like  the  TCTdiC  before  it,  is  very  concerned 
with  Assurance. 


Part  I:  The  TCSEC  Interpretations 

As  its  name  suggests.  Tart  1  of  the  TNI 
consists  of  the  interpretations  of  the  TCRFC 
roqu  iroinont.s .  The  working  group  has  gone 
through  the  TCSbC,  class  by  class  and 
requirement  by  requirement,  and  asked,  "what 
docs  this  mean  when  the  context  is  a  network, 
rather  than  a  general-purpose  operating 
system"?  Part  1  first.  restates  the 
requirement,  as  it  appears  in  no!)  3200.23- 
5TD.  The  interpretation  of  the  requirement  is 
then  stated,  followed  by  the  Rationale  for  the 
Interpretation.  In  certain  cases,  the 
Rationale  also  includes  examples  ot  mechanisms 
that  may  be  used  to  satisfy  the  requirement. 
These  examples  are  meant  to  be  just  that;  they 


arc  not  meant  to  bo  proscriptive. 

This  interpretation  makes  explicit  what  is 
implicit  in  the  TCSLC:  that  the  Criteria  can 
be  applied  to  mandatory  and  discretionary 
integrity  policies,  just  as  it  can  to 
mandatory  and  discretionary  secrecy  policies. 
That  is,  it  is  permissible  for  a  network 
system  to  support  a  secrecy  policy,  an 
integrity  policy,  or  both. 

The  evaluation  system  for  Tart  I  of  the  TNI  is 
identical  to  that  for  the  TCSLC.  A  single, 
digraph  rating  in  the  range  D  to  A1  is 
assigned  to  the  system.  This  rating  is  a 
technical  statement  of  the  amount  of  trust 
that  can  be  placed  in  the  network  system.  It 
carries  the  same  meaning  as  the  digraph  rating 
assigned  to  a  general-purpose  operating  system 
that  has  been  evaluated  against  the  the  TCSLC. 

Part  II:  Other  Security  Services 

Why  Other  Security  Services? 

Part  II  contains  additional  network  security 
concerns  that  ale  hot  reflected  in  Fait  I. 
These  concerns  are  what  differentiate  the 
network  environment  from  the  stand-alone 
computer  environment.  Some  concerns  take  on 
increased  significance  in  the  network 
environment;  others  do  not  exist  in  stand¬ 
alone  computers.  Some  of  these  concerts  are 
outside  the  scope  of  Part  I;  others  lack  the 
theoretical  basis  and  formal  analysis 
underlying  Part  1.  Since  introducing  these 
services  into  Part  I  would  destroy  the 
cohonivenc.ss  of  the  criteria  for  a  class,  they 
are  treated  separately  in  Part  II. 

Criteria  Form:  Functionality,  strength,  and 
Assurance 

Funct ional ity  refers  to  the  objective  and 
approach  of  a  security  service;  it  includes 
features,  mechanisms,  and  performance, 
strength  of  mechanism  refers  to  how  well  o 
specific  approach  may  bo  expected  to  achieve 
its  obj ectit as .  Assurance  refers  to  a  l.sis 
for  believing  that  the  functionality  will  be 
achieved;  it  includes  tanj.  er  resistance, 
correctness,  verifiability,  and  resistance 
against  circumvention  oi  bypass. 


As  an  example,  consider  communications 
integrity  protection  against  message 
modification.  A  functionality  decision  is  to 
select  error  detection  only  or  detection  and 
correction.  A  strength  of  mechanism  decision 
would  involve  how  strong  an  algorithm  to  use 
in  imulementing  whichever  were  chosen. 
Assurance  decisions  would  involve  what  level 
of  software  engineering  would  be  involved  in 
building  the  services,  whether  or  not  to  use 
formal  verification,  and  what  level  of  testing 
to  use. 

For  each  of  the  security  services  described  in 
Part  IT,  requirements  are  given  for  each  of 
Functionality,  Strength  cf  Mechanism,  and 
Assurance.  These  requirements  arc  distinct 
from  one  another,  and  may  be  met 
independently.  For  example,  it  may  be  decided 
to  implement  a  very  strong  mechanism  with  very 
low  assurance,  or  a  very  weak  mechanism  with 
veiy  high  assurance. 


The  Evaluation  System 

The  security  services  described  jn  part  II  are 
net  as  strongly  intertwined  as  are  those  ir. 
Part  I.  It  is  not  possible  to  assign  one 
rating  (e.g.,  '21')  that  adequately  reflects 

how  well  the  system  provides  each  service. 
Furthermore ,  the  services  in  Part  II  ere 
generally  not  provided  by  the  HTCB,  but  are 
provided  by  hardware/software  that  is  external 
to  the  NTCIi .  To  try  to  assign  them  a  rating 
that  is  one  of  the  digraphs  assigned  under 
Part  I  of  the  TNI  is  not  practical,  since  in 
many  cases  the  rating  assigned  is  much  more 
subjective.  Therefore,  a  qualitative  rating 
system  must  be  used,  instead  of  a 
hierarch ical 1 y-ordered  system.  The  evaluation 
system  used  in  this  document  involves  a  tuple. 
A  system  is  assigned  throe  ratings  for  each 
service:  one  each  for  Functionality,  Strength 

of  Mechanism,  and  Assurance.  Ratings  normally 
come  from  the  set  of  (Not  Olfered,  None, 
Minimum,  Fair,  Good);  however,  in  specific 
cases,  ratings  such  as  "present"  or  "approved 
for  use  with  data  up  to  SLC11LT"  may  be 
asc igned . 

Tlie  difference  between  "Net  Offered"  and 
’•None”  is  that  a  rating  of  None  states  that 
the  system  sponsor  attempted  to  provide  the 
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service  (either  Functionality,  Strength  of 
Mechanism,  or  Assurance)  and  failed 

completely.  A  rating  of  Not  Ottered  merely 
implies  that  the  sponsor  did  not  attempt  to 
provide  the  service,  as  (s)ho  did  not  consider 
it  important.  Since  cither  rating  indicates 
that  a  system  does  not  adequately  provide  a 
service,  the  only  appreciable  difference  to 
the  potential  customer  is  that  a  rating  of 
None  may  indicate  a  poor  quality  ol  work  in 
the  system. 


Selecting  Security  services 

Not  all  security  services  will  be  equally 
important  in  any  specific  environment;  nor 
will  their  relative  importance  he  the  same 
among  different  environments.  The  system's 
accreditor  (or  the  potential  customer)  must 
decide,  based  on  the  threats  to  be  encountered 
in  his/her  specific  environment,  which 
security  services  are  important,  and  which  are 
not  required.  ( S ) Ho  can  then  decide  whuthcr 
thc  rating  achieved  by  a  specitic  product  is 
adequate  for  the  projected  environment. 


General  Assurance  Approaches 

There  arc  a  number  of  factors  that  involve  the 
Assurance  ratings  of  several  security 
services.  These  assurance  factors  include 
such  things,  as  service  design  and 
implementation,  service  testing,  design 
specification  and  verification,  and 
configuration  management.  When  a  sorvict  is 
implemented,  the  rating  for  these  general 
assurance  lactors  is  combined  with  the  rating 
for  the  service-specific  assurance  factors  to 
produce  one  overall  Assurance  rating  for  the 
service . 


Supportive  Primitives 

There  are  two  mochnnisws/assurance  techniques 
that  apply  across  a  wide  range  of  services. 
These  arc  encryption  and  protocols. 
Lncrypt ion  is  a  tool  for  protecting  data  from 
compromise  or  modification  attacks.  The 
analysis  of  encryption  algorithms  and 
implementations  is  quite  different  from  the 
analysis  ol  most  o!  the  other  requirements  in 


the  TNI.  The  'I'Nl  states  that  assurance  ol 
encryption  techniques  will  be  provided  by  the 
National  Security  Agency. 

Protocols  are  a  set  of  rules  and  formats  which 
determine  the  communication  behavior  between 
entities  in  a  network.  Many  network  security 
services  ai e  implemented  with  the  help  of 
protocols.  failure  in  the  protocol  theielore 
results  in  failure  of  the  service.  Protocols 
influence  all  ratings;  there  are  Functionality 
factors,  Strength  cl  Mechanism  factors,  and 
Assurance  factors  involved. 


Gonaral  Documentation  :;«quirem»*nts 

Documentation  is  required  for  security 
services,  just  as  it  is  for  the  NTCli .  in 
fact,  in  many  cases,  the  documentation  should 
bo  contained  in  the  same  place.  For  example, 
guidance  to  the  system  or  component 
administrator  concerning  security  services 
should  probably  be  placed  in  the  Trusted 
Facility  Manual.  If  a  component  supports 
users,  guidance  to  t hose  users  should  be 
placed  in  the  security  Fcatu.res  Deer');  Guide 
required  by  Part  I.  Documentation  concur ui ng 
the  design  and  tooting  of  a  security  service 
may  be  placed  with  the  Test  Documentation  and 
Design  Documentation  required  by  part.  1;  it  it 
is  not  located  there,  then  it  must  be  provided 
separately  by  the  network  sponsor. 


Specific  Security  Cervices 

Tnc  tlner  categories  of  security  services 
addressed  are  Communications  Integrity,  Denial 
of  Service,  and  Transmission  Security. 
Communications  Integrity  is  further  broken 
down  into:  Authentication,  Communications 
Field  Integrity,  and  Non-repudiation.  Denial 
of  service  contains  the  requirements  tor 
Continuity  of  Operations,  Protocol -based 
Protection,  and  Network  Management . 
Transmission  Security  includes  Data 
Confidentiality,  Traffic  Confidentiality,  and 
Selective  Routing. 

In  Part  11,  Authentication  is  concerned  with 
wliat  the  ISO  work  calls  Peer  Fntity 
Authentication  or  Data  Origin  Authentication, 
depi  tiding  on  whether  the  service  is 
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connection-oriented  or  connectionless.  This 
can  be  contrasted  with  the  Authenticate 

required  in  Part  I,  which  is  strictly  1 _ 

Identification  and  Authentication  of  human 
users . 

Communications  Field  Integrity  refers  to  the 
protection  from  modification  of  any  or  all 
fields  involved  in  communications.  Non¬ 
repudiation  provides  unforgeatle  and 
undeniable  proof  of  shipment  and/or  receipt  of 
data . 

It.  is  accepted  that  one  can  never  completely 
protect  against  denial  of  service. 
Furthermore,  the  TNI  does  not  attempt  to 
address  protection  against  such  attacks  as 
cutting  a  communications  cable,  or  blowing  up 
one  of  the  components.  The  TNI  does  state 
requirements  for  detecting  service  levels  that 
have  fallen  below  pre-established  thresholds, 
and  for  detecting  the  fact  that  access  to  a 
component  is  unavailable. 

Transmission  security  is  a  collective  term  for 
a  number  of  security  services.  These  services 
arc  all  concerned  with  the  secrecy  of 
information  transfer  between  peer  entities 
through  the  computer  communications  network. 
While  physical  security  can  also  provide 
transmission  security,  it  is  not  explicitly 
addressed  in  the  TNI. 


Appendix  A:  Component  Evaluations 

The  main  body  of  the  TNI  takes  the  view  of  a 
network  as  a  single  trusted  system.  This  view 
can  be  extended  somewhat,  and  a  trusted 
network  car.  be  regarded  as  a  collection  of 
trusted  components.  This  is  an  important 
extension,  as  in  the  commercial  marketplace  it 
is  doubtful  that  many  vendors  will  provide 
complete  systems.  Thus,  we  would  like  to  be 
able  to  assess  the  trust  provided  by  different 
types  of  components.  Tbr-*-e  are  two  advantages 
to  being  able  to  do  this:  first,  it  allows 
for  the  evaluation  of  components  which  in  and 
of  themselves  do  not  support  all  of  the 
policies  required  by  the  TCSEC;  second,  it 
allows  for  the  reuse  of  the  evaluated 
component  in  different  networks  without  the 
need  for  a  re-evaluation  of  the  component. 


Taxonomy  of  Policies  and  components 

For  our  purposes,  there  are  four  basic  types 
of  policies  that  systems  or  components  can 
enforce.  There  are  mandatory  access  control 
policies,  discretionary  access  control 
policies,  supportive  policies,  and  application 
policies . 

Application  policies  are  those  that  apply  to 
specific  programs;  they  provide  security  in 
addition  to  that  provided  by  the  TCB  or  HTCB 
partition.  An  example  of  an  application 
policy  would  be  a  database  management  system 
that  provided  access  control  to  the  record  or 
field  level,  while  the  TCB  provides  access 
control  only  to  the  granularity  of  a  file. 
Application  policies  are  not  relevant  to  the 
TNI;  thus  they  will  not  be  addressed. 

Supportive  policies  include  identification  and 
authentication  policies  as  well  as  audit 
policies. 

Given  this  taxonomy  of  policies,  the  TNI 
breaks  the  universe  of  components  into  four 
classes .  One  class  consists  of  those 

components  that  support  mandatory  access 
control  policies;  the  TNI  denotes  these  'M 
components'.  A  second  class  consists  of  those 
components  that  support  discretionary  access 
control  policies;  the  TNI  calls  these  'D 
components'.  The  third  class  supports 

identification  and  authentication  policies, 
and  these  are  called  'I  components'.  The 
final  class  supports  audit  policies;  these  are 
called  'A  components'. 


Evaluation  System 

Whenever  a  component  is  to  be  evaluated,  the 
componen  .  sponsor  is  responsible  for 
completely  defining  a  target  network 
architecture;  that  is,  an  architecture  in 
which  the  component  is  expected  to  be  used  and 
for  which  its  security  features  will  work  as 
stated.  Once  this  is  done,  the  component  can 
be  evaluated  against  those  requirements  that 
apply  to  it,  in  the  context  of  the  stated 
target  architecture  and  policy. 

A  component  is  evaluated  against  the 


requirements  in  Part  II  as  stated  for  any 
service  it  provides.  No  further 
interpretation  is  necessary. 

A  component  is  evaluated  against  some  subset 
of  the  requirements  for  a  given  class  ir  Part 
I.  It  is  evaluated  against  all  assurance 
requirements,  plus  vhose  feature  requirements 
that  apply  directly  to  the  policy  it  enforces. 
In  general,  the  component  is  evaluated  against 
the  Interpretation  as  stated  in  Part  I  of  the 
TNI.  In  some  cases,  it  is  necessary  to 
reinterpret  the  requirement  to  place  it  in  the 
context  of  a  network  component,  rather  than  a 
network  system. 

The  range  of  ratings  that  can  be  assigned  to  a 
component  depends  on  the  policy(ies)  it 
enforces.  For  example,  a  M  component  can 
receive  a  rating  in  the  range  Bl  -  Ai.  ad 
component  can  be  rated  from  Cl  to  C2+.  (C2  + 
indicates  that  the  component  enforces  the  B3 
DAC  requirement,  and  provides  C2  assurances. 
It  is  not  correct  to  assign  a  B3  rating  to  a  D 
component,  as  that  connotes  a  level  of 
assurance  that  no  D  component  can  provide.) 
An  A  component  can  receive  a  rating  of  C2  or 
C2+,  and  an  I  component  can  be  rated  Cl 
through  C2+. 


Composition  Rules 

Since  a  component  is  defined  to  be  any  part  of 
the  system,  some  components  are  made  by 
composing  other  components.  For  example,  a 
communications  subnet  is  a  component  of  a 
larger  system;  it  may  be  composed  of  packet 
switches,  front-end  units,  and  gateways  that 
are  components  themselves.  (This  is  an 
illustration  of  the  fact  that  the  definition 
of  component  is  a  recursive  one.)  In  general 
it  is  not  possible  t.o  guarantee  that  a 
collection  of  evaluated  components  will  result 
in  an  evaluatable  trusted  system.  However,  it 
is  possible  to  define  a  set  of  composition 
rules  so  that  the  result  of  composing  trusted 
components  maintains  the  ratings  assigned  to 
the  original  components. 

An  example  of  the  composition  rules  provided 
in  the  TNI  is  illustrated  as  follows.  Suppose 
that  there  is  a  D  component  that  has  been 
given  a  C2  rating  for  D.  Suppose  that  there 


is  an  I  component  that  has  been  given  a  C'j. 
rating  for  I.  We  wish  to  compose  these  two 
components  to  get  one  DI  component  that  is 
rated  C2  for  D  and  02  for  I.  In  order  to  do 
that,  we  must  insure  that  the.  DI  component 
preserves  the  Network  DAC  Policy  of  the  D 
component.  Furthermore,  the  DI  component  must 
preserve  the  Audit  interface(s)  used  for 
exporting  audit  information  from  both  the  D 
component  and  the  I  component.  If  the  DI 
component  provides 
Identification/Authentication  support  services 
to  other  components,  the  Identification 
Interface  of  the  DI  component  must  be  defined 
and  a  protocol  established  for  this  interface 
which  is  able  to  support  the  Network  I/A 
Policy.  If  the  DI  component  does  not  provide 
Identification/Authentication  support  services 
to  other  components,  it  may  cnly  be  composed 
with  other  components  which  are  self- 
sufficient  with  respect  to  DAC. 

The  TNI  gives  composition  rules  for 
interconnecting  all  possible  combinations  of 
component  types,  most  of  which  are  similar  to 
the  one  above. 


Appendix  B:  Rationale  for  the  Partitioned 
NTCB  Approach 

Implicit  in  the  partitioned  NTCB  approach  is 
the  view  that  a  network,  including  the 
interconnected  hosts,  is  analogous  to  a  single 
trusted  system,  and  can  thus  ,e  evaluated 
using  an  interpretation  of  the  ICSEC.  Put 
another  way,  networks  form  an  important  and 
recognizable  subclass  of  ADP  systems  with 
distinctive  technical  characteristics  which 
allow  tailored  interpretations  of  the  Criteria 
to  be  formulated  for  them.  Appendix  E 
provides  the  background  and  rationale  for  the 
partitioned  NTCB  approach. 


Appendix  C;  The  "Interconnected  Accredited 
US"  View 

The  interconnected  accredited  Automated 
Information  System  (AIS)  view  is  an 
operational  perspective  that  recognizes  that 
parts  of  the  network  may  he  independently 
created,  managed,  and  accredited.  Each  AIS  is 
accredited  to  handle  sensitive  information  at 
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a  single  level  or  over  a  range  of  levels.  In 
this  view,  the  individual  AIS  may  be  thought 
of  as  "devices"  with  which  neighboring 
components  can  send  and  receive  information. 

The  interconnected  accredited  AIS  view  differs 
from  the  single  trusted  system  view  in  that, 
here,  one  does  not  regard  a  network  as  a 
single  trusted  system,  and  therefore  one  does 
not  assign  a  single  rating  to  the  network.  An 
example  of  where  the  interconnected  accredited 
AIS  view  is  necessary  is  a  network  consisting 
of  two  A1  systems  and  two  B2  systems,  all  of 
which  are  interconnected  and  all  of  which  may 
be  accessed  locally  by  some  users.  It  is  easy 
to  see  that,  if  we  regard  this  as  a  single 
trusted  system,  it  would  be  impossible  for  it 
to  achieve  a  rating  against  Part  I  of  this 
document  higher  than  B2.  This  might  not  be  an 
accurate  reflection  of  the  trust  that  could  be 
placed  in  the  two  A1  systems  and 
interconnections  between  them.  Any  single 
rating  assigned  to  this  network  would 
misleading. 


Component  Connections  and  the 
Interconnection  Rule 

Networks  like  the  one  described  above  can  only 
be  addressed  in  terms  of  whether  or  not  they 
obey  an  interconnection  rule.  Each  component 
that  is  connected  to  other  AIS  communicates  by 
means  of  a  particular  I/O  device,  which  has  a 
device  range  associated  with  it.  The 
interconnection  rule  involved  is  one  tt.at  says 
simply,  for  two  way  communication,  the  device 
ranges  of  the  two  I/O  devices  must  be 
identical.  For  one-way  communication  (i.e., 
with  no  acknowledgement  whatsoever) ,  the 
device  range  of  the  receiving  I/O  device  must 
dominate  the  device  range  of  the  sending  I/O 
device . 

This  interconnection  rule  must  be  enforced 
locally  by  each  component  of  the  network. 
Decisions  on  whether  to  send  or  receive 
information  can  be  made  by  a  component  based 
only  on  its  accreditation  range  and  those  of 
its  immediate  neighbors.  In  many  cases,  it  is 
not  necessary  for  a  sending  component  to  know 
the  accreditation  range  of  the  component  that 
is  the  ultimate  destination  of  the  message. 
If  the  interconnection  rule  is  enforced  by 


each  component,  the  overall  network  will 
prevent  information  from  being  sent  where  it 
shouldn't  go. 


The  Global  Network  View 

In  many  cases,  networks  can  enforce  the 
interconnection  rule  and  still  expose 
information  to  an  excessive  risk  of  disclosure 
or  modification.  There  are  considerations 
other  than  the  interconnection  rule  that  the 
accreditor  may  wish  to  take  into  account  when 
deciding  whether  or  not  to  permit 
interconnection  of  components.  Most  of  these 
considerations  are  based  on  a  knowledge  of  all 
the  components  in  the  network.  As  one 
particular  example  of  these  considerations, 
let  us  consider  something  called  the 
"cascading  problem".  Cascading  occurs  when  a 
penetrator  can  take  advantage  of  network 
connections  to  compromise  information  across  a 
range  of  security  levels  that  is  greater  than 
the  accreditation  range  of  any  of  the 
component  systems  he  must  defeat  to  do  so. 

Consider  the  following  example:  there  are  two 
class  H?  systems,  one  (System  A)  processing 
SECRET  and  TOP  SECRET  information,  the  other 
(System  B)  processing  CONFIDENTIAL  and  SECRET 
information.  A  penetrator  is  assumed  to  be 
able  to  overcome  tne  protection  mechanisms  in 
System  A,  causing  TOP  SECRET  information  to  be 
downgraded  to  SECRET;  have  it  sent  across  to 
System  B  at  the  SECRET  level;  and  then 
overcome  the  protection  mechanisms  in  System  B 
to  downgrade  it  to  the  CONFIDENTIAL  level. 
TOP  SECRET  information  has  thus  been 
downgraded  to  tne  CONFIDENTIAL  level. 
According  to  the  environments  guidelines  [6], 
the  risk  of  this  requires  at  least  a  class  B3 
system;  however,  the  penetrator  has  only  had 
to  defeat  two  class  B2  systems. 

The  TNI  describes  t.wo  heuristic  algorithms  for 
determining  the  presence  of  cascading 
conditions.  One,  which  is  very  simple,  is 
lairly  conservative ,  and  sometimes  indicates 
the  presence  of  a  cascading  condition  when  in 
fact  none  exists.  The  second  is  much  more 
complex,  but  it  tends  to  be  more  accurate  in 
determining  cascading  conditions. 

There  are  several  ways  of  remedying  potential 


cascading  conditions.  In  most  cases,  using  a  System  Evaluation  Criteria  in  specific 
higher  level  of  trusted  system  will  suffice.  Environments .  CSC-STD-003-85,  25  June  1985. 

In  other  situations,  mechanisms  such  as  end- 

to-end  encryption  will  solve  the  problem.  In  For  More  Information; 
extreme  cases,  the  accreditor  may  wish  to 

actually  disallow  the  connection.  The  author  can  be  contacted  at  the  following 

address: 
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I.  Introduction  to  OSI  Security 

The  Open  Systems  Interconnection  (CSI) 
computer  network  architecture  has  given 
computer  network  designers  and  implementors 
a  common  vocabulary  and  structure  for 
building  future  networks.  It  has  also 
given  network  security  designers  a 
foundation  upon  which  desired  security 
services  can  be  defined  and  built.  This 
paper  discusses  several  goals  of  security 
in' the  OSI  architecture  as  well  as  where 
and  how  the  security  services  that  satisfy 
them  could  be  implemented. 

A.  Need  for  a  Security  Architecture 

A  standard  security  architecture  is 
needed  in  OSI  in  order  to  begin  the  task  of 
implementing  security  services  in 
commercial  products  so  that  not  only  can 
one  OSI  system  communicate  with  another, 
but  also  it  can  do  the  communication  with 
the  desired  security.  The  security  goals 
and  services  discussed  in  this  paper  are 
predicated  on  the  assumptions  that 
sensitive  or  valuable  data  are  being 
transmitted  between  systems  in  the  OSI 
network,  that  changes  in  the  network 
between  the  systems  could  be  made  by  an 
unauthorized  person  or  persons  in  order  to 
obtain  or  modify  the  data,  and  that 
security  services  are  to  me  available  in 
the  network  to  prevent  the  unauthorized 
disclosure  of  sensitive  data  and  to  detect 
(and  report)  the  unauthorized  modification 
of  data. 

For  this  paper,  security  is  defined  to 
be  the  protection  of  the  confidentiality 
and  integrity  of  data.  Privacy,  often 
combined  with  security  or  confused  with 
security,  is  a  social  issue  regarding 
protection  of  personal  information  from 
undesirable  use  and  is  not  discussed  in 
this  paper.  Security  is  often  defined  as 
including  protecting  the  availability  of 
data  but  is  not  included  in  the  scope  of 
this  paper. 

B-  Requirements  for  Security 

A  large  number  of  potentially 
desirable  security  goals  in  computer 
networks  have  been  identified  in  the 
literature.  The  OSI  Implementors  Workshop 
Special  Interest  Group  in  Security  (osi 
SIG-SEC)  is  establishing  a  desirable  set  of 
security  goals  for  implementors  of  OSI  and 
the  resulting  list  of  desirable  services  to 
implement.  This  SIG  is  sponsored  by  the  U 
S.  National  Bureau  of  Standards  and  is  open 
to  anyone  interested  in  OSI  security. 

NOTE:  CONTRIBUTION  OF  THE  NATIONAL 
BUREAU  OF  STANDARDS. 
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A  minimum  set  of  desirable  security 
goals  in  OSI  identified  by  the  author  is: 

1.  Protection  of  data  against 
unauthorized  modification. 

2.  Protection  of  data  against 
undetected  loss/repetition. 

3.  Protection  of  data  against 
unauthorized  disclosure. 

4.  Assurance  of  the  correct  identity 
of  the  sender  of  data. 

5.  Assurance  of  the  correct  receiver 
of  the  data. 

As  a  memory  aid  for  these  five  basic 
security  goals,  the  following  five  terms 
starting  with  the  letter  "S"  have  been 
selected  to  represent  the  security  achieved 
by  satisfying  these  goals.  They  are, 
respectively: 

1.  Sealed 

2.  Sequenced 

O  !■< 

•J  .  OUWi.  d  u. 

4.  Signed 

5.  Stamped 

Achieving  these  security  goals  in  the 
OSI  architecture  will  assure  that  data 
being  transmitted  from  one  OSI  system  to 
another  will  not  have  been  modified, 
disclosed,  replayed,  or  lost  in  the  network 
without  the  sender  and/or  the  intended 
receiver  being  notified  and  that  the 
participating  parties  in  the  communication 
have  been  correctly  identified. 

Other  security  goals  that  have  been 
identified  (IX)  as  being  desirable  include: 
labeling  of  data  according  to  its 
sensitivity,  source,  etc.;  not  disclosing 
the  identities  of  the  sender  and  recipient 
of  data,  and  the  quantity  of  data 
exchanged,  except  to  each  other;  providing 
security  audit  trails  of  network 
communications;  assuring  the  availability 
of  communications  under  adverse  conditions; 
assuring  that  data  inside  an  OSI  system 
cannot  be  transmitted  using  covert 
information  channels,  even  of  very  low 
bandwidth;  proving  to  an  independent  third 
party  that  a  communicat ion  did  occur  and 
the  correct  contents  were  received; 
obtaining  explicit  authorization  for  access 
to  a  system  before  making  a  connection  to 
the  system. 

C.  National  Bureau  of  Standard's  Role 

The  National  Bureau  of  Standards  (NBS) 
has  fostered  the  development  of  the  OSI 
architecture  and  the  implementation  of 
commercial  products  implementing  the 
standard  protocols  defined  for  the 
architecture.  NBS  has  had  a  program  in 


computer  security  since  1973  and  has 
fostared  the  development  of  numerous 
security  standards  [7,  a,  9,  10]  since  that 
time.  It  has  assisted  in  the  development 
of  several  security  standards  in  the 
banking  community  (4,  5,  G]  and  the 
information  processing  community  [1,  2,  3] 
through  the  American  National  Standards 
Institute.  It  is  now  supporting  the 
development  of  an  CGI  security  architecture 
[11]  via  the  ISO/  TC97/  ."021/  WG1  and  the 
OSI  SIG-SEC. 

II.  OSI  Network  Security  Perimeters 


A  useful  notion  in  the  development, 
implementation  and  use  of  security  in  a 
computer  network  is  that  of  a  security 
perimeter.  This  logical  structure  in  a 
computer  network  is  the  equivalent  to  a 
physical  structure  in  a  secure  facility 
such  as  a  bank  vault.  In  actuality  there 
are  multiple  security  perimeters  around 
highly  secure  facilities  where  a  principal 
of  "security  in  depth"  is  practiced, 
similar  analogies  can  be  drawn  in  computer 
networks.  For  simplicity  in  this 
discussion,  a  single  security  perimeter 
concept  will  be  used  in  which  each  OSI 
system  will  have  a  security  perimeter.  The 
overall  goal  of  OSI  security  is  to 
communicate  data  from  within  one  security 
perimeter  to  another.  Loss  of  security 
within  a  perimeter  is  beyond  the  scope  of 
this  paper. 

A.  One  Security  Perimeter  around  Network 


If  a  security  perimeter  is  drawn 
around  the  entire  network  (Figure  1) , 
either  because  no  sensitive  or  valuable 
data  are  ever  communicated  in  the  network, 
because  no  threats  are  believed  to  exist  in 
the  network,  or  because  security  it 
provided  through  non-OSl  methods,  then  no 
osi  security  services  are  needed.  Many 
networks  are  presently  being  operated  in 
this  manner.  This  is  acceptable  as  long  as 
everyone  arid  everything  inside  the 
perimeter  is  "trusted."  Trust  implies  that 
no  intentional  or  accidental  event  will 
occur  which  will  result  in  an  undesirable 
disclosure,  modification  or  loss  of  data. 

A  simplified  definition  of  trust  is  used  in 
this  paper  with  trust  being  a  binary  valued 
parameter  (i.e.,  multi-level  security  is 
not  considered) .  Trust  can  also  be  assured 
within  the  system  through  the  use  oi  a 
"Trusted  Operating  System."  This  system 
assures  that  adequate  security  is  provided 
within  the  security  perimeter. 

P  User  Processes  P 

7  Application  Layer  7 

G  Presentation  Layer  6 

5  Session  Layer  5 

4  Transport  Layer  4 

3  Network  Layer  3 

2  Link  Layer  2 

1  Physical  Layer  1 

Figure  l:  One  Secu rity  Perimeter  around 
network 


li.  Security  Perimeter  around  each  User 
Process 

A  security  perimeter  could  be  drawn 
around  each  user  process  which  provides 
high  granularity  security  (Figure  2)  since 
each  user  process  provides  its  own 
protection  anu  nothing  within  the  OF 1 
architecture  needs  to  be  trusted.  However, 
this  requires  that  all  desired  security- 
services  be  implemented  in  every  user 
process  or  program.  While  possible,  this 
approach  is  contrary  to  the  goal  of  OSI  for 
performing  services  in  the  layers  of  OSI 
rather  than  in  each  user  process. 
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Fiqure  2:  security  Perimeter  around  each 
User  Process 


C.  Security  Perimeter  around  Upoer 
Layers 


A  security  perimeter  can  »e  drawn 
between  these  two  extremes  around  the  upper 
layers  of  the  OSI  architecture.  Different 
granularities  of  security  result  from 
selecting  different  placement  of  the 
security  perimeter.  In  actuality,  a 
hierarchy  of  security  perimeters  will  be 
implemented,  each  providing  security 
against  a  different  perceived  threat,  A 
security  perimeter  has  been  drawn  at.  the 
transport  layer  (layer  4)  of  the  OSI 
architecture  (Figure  3)  for  subsequent 
discussion  in  this  paper 
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Fiqure  3:  Security  Perimeter  around 
Upper  Layers 


_ Negotiated  Security 

One  goal  of  OSI  implementors  should  be 
to  provide  maximum  flexibility  for  users  of 
an  implementation.  An  .impleme-ntation 
should  provide  for  negotiation  between 
users  in  selectir  an  optimum  set  of  OSI 
services,  includ..  ig  security’  services. 
However,  security  may  be  somewhat  unique  in 
this  regard  in  that  some  organizations  may 
not  desire  to  negotiate  certain  security 
services,  especially  if  the  negotiation 
could  result  in  security  less  than  some 
predetermined  minimum.  Other  organizations 
may  accept  negotiating  away  all  security 
services  if  those  services  are  temporarily' 
causing  functionality  or  throughput  to  drop 
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below  a  minimum.  Some  organizations  may 
add  to  the  basic  security  services  provided 
in  standard  implementations  and  not  desire 
other  organizations  to  use  or  know  about 
the  additional  services. 

An  extensible  security  architecture  is 
desired  which  will  provide  for  these 
special  services  without  causing  an 
unacceptable  overhead  on  those  not 
requiring  these  services. 

Ill-  Placement  of  Security  Services  in 
the  OSI  Architecture 

A.  Security  Addendum  to  the  OSI 
Architecture 

A  draft  security  addendum  to  the  OSI 
architecture  [11]  has  been  developed  by  Ad 
Hoc  groups  of  the  American  National 
Standards  Institute  (ANSI)  and  the 
International  Standards  Organization  (ISO) 
TC97/  SC2 1/  WG1.  The  draft  security 
addendum,  presents  a  glossary  of  computer 
security  terms,  describes  a  number  of 
security  services  for  OSI,  and  presents  a 
matrix  of  where  in  the  seven  layer  OSI 
architecture  the  security  services  may  be 
located  (See  Below) .  It  then  presents  the 
rationale  for  why  the  security  services  are 
placed  in  those  layers.  Recent  work  [12] 
defines  an  authentication  framework  for  the 
layer  7  directory  service  for  which  User 
Agents  are  authenticated  before  they  are 
granted  access  to  sensitive  information  in 
the  Directory. 

While  the  draft  addendum  satisfies  the 
goals  of  definirg  a  number  of  security 
services  and  discussing  where  they  could  be 
placed,  the  addendum  is  not  adequate  for  an 
implementor  desiring  to  implement  security 
in  the  OSI  architecture.  First,  it  would 
be  too  expensive  to  provide  all  security 
services  at  all  possible  layers  allowed  in 
the  addendum.  Second,  if  one  implementor 
chose  to  implement  a  service  at  one  layer 
and  another  implementor  chose  to  implement 
the  same  service  at  a  different  layer,  the 
goal  of  compatability  between  peer  layers 
of  OSI  would  not  be  achieved.  Finally, 
standards  for  implementing  the  services  are 
not  currently  specified. 

B.  OSI  Security  Categories  and  Services 

The  following  security  categories  and 
services  are  defined  in  the  draft  security 
addendum  to  the  OSI  architecture.  The  OSI 
layers  in  which  the  services  could  be 
implemented  are  shown  in  the  matrix  next  to 
the  services.  The  services  need  not  be 
implemented  in  all  of  the  layers  that  are 
specified. 


OSI  SECURITY  SERVICE  PLACEMENT  PRIORITIES 


High  (B) ;  Medium  (M) ;  Low  (L) 
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c. 

Factors 

in  Placing  Security  Services 

Many  factors  must  be  considered  in 
selecting  the  layer (s)  for  implementing 
selected  security  services.  First,  a  basic 
set  of  security  services  to  be  implemented 
roust  be  chosen.  Second,  a  minimum  number 
of  layers  should  be  chosen  in  which  to 
implement  the  services  to  minimize  the 
number  of  layers  affected  by  security. 
Third,  use  of  existing  services  of  a  layer 
may  be  utilized  by  the  security  service  if 
a  proper  layer  is  chosen.  Fourth,  the 
overall  cost  of  providin'.;  the  selected 
security  services  will  be-  minimized  if  the 
layer  is  properly  selected. 

Fifth,  a  set  of  primitive  security 
functions  need  to  be  defined  and 
implemented  (hardware,  software,  firmware) 
in  such  a  way  that  they  can  be  performed  at 
one  or  more  layers  of  the  architecture  in 
providing  the  desired  security  service. 

D.  Primitive  Security  Functions 


OSI  security  services  could  be 
implemented  utilizing  a  set  of  primitive 
functions  similar  to  the  ones  below.  The 
primitive  functions  would  be  called  with  a 
set  of  parameters  enclosed  in  [ ) 
and  return  the  results  enclosed  in  ( ) 
following  execution. 


1] 


I.  AUTHENTICATE  [ID;  AUTHENTICATOR] 
(RESULT ;  STATUS) 

This  primitive  verifies  that  che 
AUTHENTICATOR  does  correspond  with  the 
claimed  ID  by  searching  the  local  Secure 
Management  Information  Base  and  responding 
with  the  correct  RESULT  and  STATUS. 

II.  AUTHORIZE  [ID;  TYPE;  RESOURCE] 
(RESULT;  STATUS) 

This  primitive  verifies  the 
authorization  of  ID  with  the  indicated  TYPE 
for  access  to  the  requested  RESOURCE  and 
sets  the  correct  RESULT  and  STATUS. 

III.  ENCIPHER  [PT;  LENGTH;  KEYNAME]  (CT; 
LENGTH;  STATUS) 

This  primitive  enciphers  plaintext 
beginning  at  PT  for  the  indicated  LENGTH 
into  ciphertext  beginning  at  CT  for  the 
indicated  LENGTH  and  sets  the  resulting 
STATUS  using  the  KEY  associated  with 
KEYNAME. 

IV.  DECIPHER  [CT;  LENGTH;  KEYNAME]  (PT; 
LENGTH;  STATUS) 

This  primitive  deciphers  ciphertext 
beginning  at  CT  for"  the  indicated  LENGTH 
into  plaintext  beginning  at  PT  for  the 
indicated  LENGTH  and  sets  the  resulting 
STATUS  using  the  KEY  associated  with 
KEYNAME. 

V.  COMPUTEMAC  [DATA;  LENGTH;  KEYNAME 1 
(MAC;  STATUS) 

This  primitive  computes  a  Message 
Authentication  Code  (MAC)  on  the  DATA  of 
indicated  LENGTH  using  the  KEY  associated 
with  KEYNAME  and  sats  the  resulting  STATUS. 

VI.  VERIFYMAC  [DATA;  LENGTH;  KEYNAME ; 
MAC]  (RESULT) 

This  primitive  computes  a  Test  Message 
Authentication  Code  (TMAC)  on  the  DATA  of 
indicated  LENGTH  using  the  KEY  associated 
with  KEYNAME  and  sets  the  correct  RESULT  to 
indicate  if  TMAC  is  identical  with  the 
input  MAC. 

VII.  SIGN  [DATA;  LENGTH;  USERID; 

KEYNAME]  (SIGNATURE;  STATUS) 

This  primitive  computes  a  SIGNATURE  on 
the  DATA  of  indicated  LENGTH  for  the  user 
indicated  by  USERID  using  the  KEY 
associated  with  KEYNAME  and  sets  the 
resulting  STATUS. 

VIII.  VERI FYS1GNATURE  [DATA;  LENGTH; 
USERID;  KEY'NAME]  (SIGNATURE; 
(RESULT; STATUS) 

This  primitive  computes  a  Test 
Signature  (’(’SIGNATURE)  on  the  DATA  of 
indicated  LENGTH  for  the  user  indicated  by 
USERID  using  the  KEY  associated  with 
KEYNAME,  compares  it  with  SIGNPTURE,  and 
sots  the  correct  result  and  STATUS. 


E.  Initial  Recommendations  for 
Placement 

Based  on  the  simplifying  assumptions 
stated  at  the  beginning  of  this  paper,  the 
transport  layer  (4)  of  the  OSI  architecture 
was  chosen  by  NRS  for  initial 
implementation  of  a  selected  subset  of 
security  services.  This  layer  was  chosen 
after  several  years  of  participating  in  the 
development  of  standards  for  security  at 
layers  1/2  [2],  layer  4  [13]  and  layer  6  of 
the  OSI  architecture  by  the  accredited  ANSI 
Technical  Committee  X3T1.  The  layer  1/2 
standard  was  developed  for  protecting  data 
in  each  link  of  a  network.  However,  it 
does  not  provide  security  from  one  OSI 
end-system  computer  to  another  through  a 
general  network.  A  layer  4  standard  was 
drafted  to  provide  security  for  all  data  in 
a  layer  4,  class  4  connection.  A  layer  6 
standard  was  drafted  to  provide  security 
for  selected  fields;  of  data  specified  by  an 
application  in  such  a  way  that  it  need  not 
be  unprotected  even  at  the.  intended 
destination. 

Early  development  of  the  layer  4 
standard  was  facilitated  by  an  early 
definition  of  services  at  layer  4  and  the 
existence  of  standard  protocols  and 
implementations  of  layer  4.  It  was  also 
facilitated  by  using  existing  services  of 
layer  4  for  security  purposes. 

IV.  Protocols  for  T ransport  layer 
Security  Services 

A.  Integrity  Service 

A  connection  integrity  service 
protocol  has  been  defined  for  class  4  of 
the  transport  layer  (4)  of  the  OSI 
architecture.  The  integrity  service  can 
achieve  two  security  goals,  sealing  and 
sequencing,  and  assures  that  all  data  in  a 
connection  are  transferred  from  one  OSI 
security  perimeter  to  another  without  being 
intentionally  or  accidentally  modified, 
lost  or  repeated.  Such  security  is 
especially  important  in  Electronic  Funds 
Transfer  (EFT)  transactions.  EFT  messages 
are  vulnerable  to  modification;  deposit  and 
withdrawal  messages  are  vulnerable  to  loss 
or  repetition.  While  present  EFT  security 
standards  specify  security  services  at 
layer  7  of  the  OSI  architecture,  a  wide 
variety  of  other  applications  cou.d  utilize 
similar  security  services  if  they  are 
implemented  at  layer  4. 

The  integrity  service  protocol 
utilizes  the  sequence  number  provided  by 
layer  4,  class  4  service.  This  is  a  31-bit. 
number  defined  as  4  octets  in  the  header  of 
each  layer  4  Protocol  Data  Unit  (PDU) .  The 
sequence  number  is  provided  by  layer  4  for 
resequencing  the  PDUs  if  they  arrive  out  of 
order  and  for  flow  control  on  a  connection. 
The  integrity  service  also  utilizes  the 
existing  layer  4,  class  4  mechanisms  for 
recovery  from  errors  (i.e.,  lost  or 
modified  data).  Connectionless  network 
layer  (3)  services  can  then  be  used  if  a 
class  4  integrity  service  is  provided  and 
used  at  layer  4. 


The  PDU  integrity  protocol  specifies 
how  an  electronic  data  integrity  seal, 
called  a  Message  Authentication  Code  (MAC) , 
is  computed  for  each  PDU.  The  seal  covers 
both  the  user  data  and  the  header 
(including  sequence  numbers)  for  data 
stream  integrity.  The  seal  is  typically  a 
32-bit  number  that  is  computed  using 
cryptographic  functions  on  the  PDU  to  be 
sealed  so  that  its  integrity  can  be 
verified  when  it  is  received  at  the 
corresponding  security  perimeter  (layer  4 
peer  entity) .  If  any  part  of  the  PDU  has 
been  accidentally  or  intentionally 
modified,  including  the  address  and 
sequence  number,  the  test  value  computed  on 
the  received  PDU  will  not  match  with  the 
seal  computed  by  the  transmitter  on  the 
transmitted  PDU  and  transmitted  with  the 
sealed  PDU.  If  the  value  is  not  correct, 
the  suspected  PDU  is  discarded  and  a 
retransmission  is  requested.  If  the  value 
is  correct,  the  PDU  is  accepted.  Sequence 
numbers  are  also  verified  to  assure  data 
stream  integrity. 

B.  Confidentiality  Service 

Data  can  be  protected  against 
unauthorized  disclosure  in  a  network  with 
encipherment  (encryption) .  The  iso/osi 
security  addendum  calls  this  a 
confidentiality  service.  Enciphering  is  a 
transformation  of  data  into  a  form  that  is 
not  usable  or  readable  while  preserving  the 
information  content.  The  resulting 
ciphertext  is  tiansiuitted*  The  authorized 
receiver  must  perform  the  correct  inverse 
operation,  called  deciphering  (decryption) , 
in  order  to  obtain  the  original,  usable, 
readable,  form  of  the  data.  Typically,  a 
cryptographic  algorithm,  implemented  in  a 
computer  with  either  hardware,  software  or 
both,  and  a  cryptographic  variable  called  a 
key  are  used  to  perform  the  two  required 
transformations.  A  requirement  of  this 
service  is  that  something  be  kept  secret  or 
available  only  to  authorized  communicating 
parties.  Details  of  this  service  are 
beyond  the  scope  of  this  paper. 

The  confidentiality  service  requires 
that  the  user  data  of  a  PDU  be  enciphered 
before  leaving  the  security  perimeter  of 
the  transmitter  and  be  deciphered  only 
after  entering  the  security  perimeter  of 
the  intended  receiver.  Other  portions  of 
the  PDU  need  not  be  enciphered  since  they 
contain  no  user  data.  If  enciphering  is 
performed  only  on  the  user  data,  the 
addresses  or  identities  of  the 
communicating  parties  are  not  enciphered 
and  hence  a  monitor  in  the  network  can 
determine  who  is  communicating  and  how  much 
data  in  being  communicated,  even  though  the 
contents  of  the  data  cannot  be  determined. 

The  OSl  security  architecture 
specifies  a  traffic  flow  confidentiality 
service  at  layer  1  to  protect  against 
traffic  analysis  if  this  protection  is 
desired.  Encipherment  at  this  layer  would 
protect  all  data  on  a  communication  link, 
including  the  addresses  of  the 
communicating  entities.  However,  it  would 
be  unprotected  in  all  intervening  gateways. 


1  3 


C.  Peer  Authentication  Service 

The  two  communicating  transport  layers 
are  called  peer  entities  and  must  perform 
equivalent  services  in  order  to 
communicate.  Simpl istical ly ,  what  one  does 
the  other  must  check  and/or  undo.  The 
security  protocols  that  have  been  defined 
to  date  at  layer  4  will  assure  that  the 
peer  layers  are  mutually  identified  and 
that,  a  connection  between  them  is  a  current 
connection  and  not  a  rep  . ay  of  a  previous 
connection.  This  protocol  relies  on 
crypt.' graphic  procedures  during  the 
establishment  of  a  connection.  Once  a 
connection  is  established,  data  intended 
for  the  peer  layer  4  can  only  be  used  by 
that  peer  entity.  It  can  be  accidentally 
cr  intentionally  destroyed,  delayed  or 
misrouted,  but  it  cannot  be  used  by  the 
unauthorized  receiver  if  encrypted. 

Peer  authentication  is  performed  by  a 
connection  procedure  often  called  a 
three-way  handshake,  using  proper 
cryptographic  procedures,  a 
challenge--response-verif ication  is 
performed  by  both  peer  entities  of  a 
connection.  Random  numbers  are  used  in  a 
standard  procedure  to  assure  that  both  peer 
entities  have  the  correct  key  and  that  a 
replay  of  a  previous  connection  is  not 
being  attempted.  The  user  data  is  not 
signed  with  this  technique.  The  personal 
identities  of  the  users  of  a  connection  or 
the  applications  using  a  connection  are  not 
involved  in  this  service.  It  merely 
assures  that  an  entire  stream  of  data  is 
not  replayed  to  an  unsuspecting  recipient. 

V.  NBS  Laboratory  Implementation 

A.  Local  Area  Network  Environment 

The  National  Bureau  of  Standards 
initiated  an  experiment  in  implementing 
these  security  protocols  in  the  transport 
layer  of  several  computer  systems  in  a 
local  area  network  environment.  The 
experiment  was  to  determine  the  adequacy  of 
a  proposed  ANSI  standard  for  the  security 
protocols,  the  ease  of  implementation  and 
impact  on  the  operation  of  the  network. 

The  network  was  based  on  one  of  the 
IEEE  802  standards  often  called  Ethernet. 
Six  personal  computers  were  used  for  the 
experiment.  Ethernet  circuit  boards  were 
added  to  the  computers  and  connected 
together  using  coaxial  cable,  software 
supplied  with  each  Ethernet  board  was  used 
r o  provide  layer  1,  2  and  3  functionality. 

A  transport  layer  protocol  that  was 
implemented  on  a  time— shared  mini— computer 
was  used  as  the  basis  of  the  experiment. 
Null  layers  5  and  6  were  used.  A  simple 
layer  7  application  was  used  to  demonstrate 
connections  and  data  transfers  among  the 
computers . 

The  National  Bureau  of  Standards  Data 
Encryption  Standard  (DES)  was  used  for  the 
cryptographic  functions,  six  circuit 
boards'each  containing  DES  devices  were 
obtained  from  two  companies  and  plugged 
into  the  six  personal  computers.  These 
boards  were  used  by  the  layer  4  security 
services.  Cryptographic  keys  for  each  of 
the  six  computers  were  manually  installed 
in  the  computers  for  demonstrations.  No 
automated  key  management  was  performed 
during  the  experiment. 


B.  Lessons  Learned 

The  difficulty  of  converting  a 
protocol  designed  for  a  time -shared, 
interrupt  driven  mini-computer  to  a 
single-user,  event  driven  personal  computer 
was  not  anticipated.  Even  though  the 
programming  language  was  the  same  on  both 
systems,  it  was  found  to  be  very  difficult 
to  convert  the  program  from  one  system  to 
another.  A  completely  new  system  interface 
had  to  be  developed  in  order  to  use  the 
services  of  the  transport  protocol. 

It  was  found  to  be  easy  to  integrate 
the  security  services  into  the  transport 
protocol  once  the  protocol  was  working. 

The  confidentiality  service  was  the  easiest 
to  implement.  The  integrity  service  was 
the  most  difficult  as  it  reguired  more 
modifications  of  existing  layer  4 
functions.  The  peer  authentication  service 
was  trivial  after  implementing  the 
integrity  service,  since  the  system  was 
designed  only  for  demonstration,  there  was 
no  attempt  to  verify  the  correctness  and 
trust  of  the  implementing  code  itself  which 
would  be  necessary  for  operational  systems. 

It  was  difficult  to  effectively 
demonstrate  security  of  the  network.  Good 
security  implementations  should  have 
minimal  effects  on  the  user  and  the 
network.  It  was  often  impossible  to  tell 
if  the  security  services  were  being 
performed  since  they  caused  negligible 
overhead  on  the  network.  A  network  monitor 
was  finally  designed  to  observe  the  data  on 
the  network  so  that  security  services,  or 
lack  thereof,  could  be  observed. 

It  was  acceptable  to  have  special 
applications  to  demonstrate  the  security 
services  and  the  transport  services  but  it 
was  apparent  that  original  equipment  and 
software  implementors  and  vendors  have  to 
support  the  enhanced  security  functions  as 
a  basic  feature  of  their  product  in  future 
products  in  order  to  gain  the  desired 
security  and  user  support.  The  interface 
to  security  enhancements  has  to  be  trusted 
and  integrated  into  the  product  or  security 
will  often  be  bypassed. 

VI.  summary  and  Conclusions 

A  security  architecture  is  needed  as  a 
fundamental  part  of  the  OSI  architecture. 
Standard  security  services  must  be  defined, 
standard  security  protocols  must  be. 
developed  and  standard  security  interfaces 
for  applications  programs  must  be 
specified.  Optional  security  services  must 
be  defined  and  standard  implementations 
must  be  available  to  be  used  on  an  optional 
basis.  All  security  services  need  to  be 
negotiated  but  with  provisions  for  default 
services  and  enhanced,  user  defined 
services.  The  user  should  not  be  aware  of 
the  operation  of  security  services  other 
than  the  need  for  providing  initial 
information  for  the  service  (e.g.,  the  set 
of  services  required,  specific  parameters 
for  the  service  if  default  parameters  are 
not  acceptable) . 


While  only  a  small  subset  of  the 
possible  desirable  security  services  were 
selected  for  discussion  in  this  paper, 
there  is  a  need  for  research  in  providing 
additional  services  and  for  standards 
activities  l'or  specifying  implementations 
of  them.  The  National  Bureau  of  Standards 
is  seeking  interest  and  assistance  in 
providing  these  necessary  activities. 
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ABSTRACT 

Computer  nelwoiks  stippoi  t  i no  conunmi  ami 
control  mission:;  i  nl  cl  connect  senseis, 
opeiat  ions  Contois,  1  oi  res  and  ut  lici 
hot  or  o.jc'ncons  systems.  Such  "systems  of 
^yst.oms"  must  pi  ot  net  sensitive  data  J  i  om  tin.' 
tliic.it  ut  compromise  ami  must,  in  addit  ion, 
I'tovicie  prelect  ion  to  mission  nit  ic.il  data 
and  resouices  against  1  os.:;-o t  - i  m  e.ji  i t  y  and 
deni. a  1  _oi -set  vi ce  .  This  papet  pit-sents  an 
approach  to  netwoik  security  that  t  teals 
Si'nsit  i  v  1 1  y  (e]  asni  j  j  e.i  ri.it  a  pi  ot  eel  ion) 
issues  independent.  01  etiticality  (  .  nt  entity 
and  aval  1  al’i  1  i ;  y )  issues  to  yain  a'ohi- 
'eciuial  and  economi  c  aavatil see .  Decompo¬ 
sition  oi  luge  system;;  into  oonpoiioul  is 
leviewed.  We  discuss  p:  election  moch.ni  i  sms  to 
count  ot  sons  i  •  j  v  i  t  y  and  eiit  icality  tlne.it  s 
and  also  .nidi  onr.  scout  it  y  intoi  l.i.’r  policy 
i  oqu  ;  r  einoni  s  het  ween  component  :■  ami  systems, 
i'inally,  a  network  poem  ity  a  i  eh  i  t  ce;  u  i  < 
concert  is  suggested. 

INTRODUCTION 

Net  vsoi  ki;  and  mote  specj l  i cal  1 y 

<1  j  st  i  5  hut  oci  systems  p.  eseni  a  no;  r  dill  ictilt 
secui  it  y  j'lobiem  than  mono!  i  t hi e  computet 
Syst  cut::  due  to  lack  ol  CenLr.il  rout  l  o)  and  a 
heightened  seen  >  ity  exposui  e  that  is  geo¬ 
graphically  di spot sed  and  ovei  a  In  oade. 
t.'ingf’  oi  levels.  Conmnini  cat  ing  component  s 
compound  tin'  problems  with  ditteient  seem  ity 
Policies  and  intri  nuv.s,  j  ncomp.it  i t>] e 

seen)  i 1  y  a  tchi  tort  tires ,  and  composite  links. 
There  is  a  lack  o*  nt  i  ong  technology  histoiy 
in  network  kern  i  i  L  y  and  oxteiii.il  e;:pesiu  e  ol 
communieat  ions  media  and  i  aoi  1  1 1  ies  pi  rvi.lrs 
theater  oi'poi  t  tin  i  t.y  lot  imogtity  and  denial 
of  sci vi ce  attacks. 

In  coiiuiiuii  i  cat  i  onr.  syst  oms  we  pi  uteri 
data  content  oxposuie  with  ri  ypt  og  t  apliy ,  but 
Without  additional  pi  ot  ect  ion  (not  pieSently 
novided  in  computet  seem  ity),  l.ils.e 
.ll'ossa9,'s  can  be  initiated,  i  mpoi  t  ant  message:; 
can  be  deleted,  and  comiminicaLions  lcsouicrs 
could  be  made  unavailable.  To  make  matters 
more  difficult.,  a  probable  piofile  of  today's, 
enemy  is  someone  who  lias  a  seem  it  y 
clearance,  has  dedicated  many  yea i s  srivire 
to  the  Goveinment,  and  possossca  detailed 
Technical  knowledge  of  computet  hardware  .ml 
software. 

We  examined  hob'  -'.  del  ived  seem  it  y 
Policy  and  tound  ilia'  it  ptimiiiiy  .ui.li  i-sses 
mono!  i '  hie  Computer  systems  in  a  ptot  voted 
Chvi  I'binnent  •  It  is  not  definitive  whole 


complexity  exists  and  deals  pt  i  ne  lp.i  1  1  y  with 
i nl Ol mat  i on  pi ol  ort ion  issues  (not  mission 
1  ot  eel  i  an  issues).  I'm  I  liri  ,  connect  j  ng 
i  .uipment  in  bob  )  list  a  1  1  at  i  onr  appeals  to  be 
leading  t  o  the  lr.iuiiriiirnt  1  0)  all  highly 
i"i  it  i  ca  1 /b  i  gh.l  y  classified  systems,  to  be 
cei  t  i  1  i  cd/.trri  edi  5  e.i  at  least  to  t  lie  A1 
(Orange  book  [1])  level.  This.  is  a 
technologically  dillieult  goal  that  nugniiies 
development  cost  and  can  impose  in  its. 

solut  ion  .uiaccept  al'ie  i  ,  .)  at  i  oi.a  1  cens.t  i  a  i;;t  s 
and  i  i  sk  s. . 

This-  popet  sepal  at  es  sensitivity 

(pi  ol  eel  i  on  ol  cl  as.s.i  1  i  cd  iiileiin.il  iru)  I  i  oiu 
ciiticality  (inlegijty  ol  opeiat  ions.  and 
pi  ol  eel  ion  against  denial  ol  services).  This, 
division  lesults  in  the  ability  to  use 

enciypiion  and  eeveit  channel  pi ot ect  i on 
nieeli.uii  SIUS  to  solve  tile  sennit  ivity  pioblem 
in  host  eemiuun  i  c.ii  i  on-  .m.i  .hit  a  :'-t  Li  ,i._u  , 
leaving  the  ei  it  utility  pi  obi  cm  to  be 
add: es: ed .  Ciiticality  Can  nenei a  1 1 y  be 
solved  in  notwoiks  with  b  ectien  and 
).  oeovoiy  apj  >i  o.ielu  exis-tini  pi  im.it  ily  in 

tlw  host  pt  ol  ect  e.i  domain;  whieli  i  •:  la:  les.s. 

cost  ]y  than  tesiutivo  (!  u  tr.a  1  model) 

mechanisms.  V.'e  brlirw  this  solution  will 
not  only  l  educe  opeiation.il  rrm  t  Mint  but 
will  also  piovidi  a  less  expensive  appi each 
to  even  a  higliei  level  oi  s.ocuiity. 


SENSITIVITY  AND  CRITICALITY 
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security,  intoyijty  has  only  applied  to  the 
t  t  tinted  computet  base  and  denial  ot  service 
was  not  sciiously  addieso.od.  In  not  woi  ks , 
integrity  and  ava  j  ]  abi  1  i  t  y  concept  s  apply  to 

coiiimun  i  oat  i  on  contiol  (o..j.,  key  diet  li¬ 

bation,  pi ot cents),  eoni  to)  pi Coonses,  and 
inoeli.in  i  sms  (in  :i  in  innei  siniil.it  to  the 
t  i  list  i'd  com)  at  oi  base).  Net  woi  k  Jeyuiie- 

niont  l  u  1 1  1 10 1  poitain  to  d  i  st  l  i  but  i  on  paths 
and  opt  i  on:; . 

The  out  iio  cent  i  ol  moolianism  must  be 
t  i  ust  od  to  some  Jeyiee.  The  concept::  ol 

detection  and  icoovoiy  apply  to  data  ami  data 
('.it  li  alteration,  as  well  as  t.o  i  n.ippi  opt  i  at  e 
oi  .maul  hoi  i  zed  les.ouice  mo.  Tile  inieyiity 
ol  |'i'iil  eel  ion  median  i  sms,  concei  ned  with 
c'l'nii'ipinuio  oi  e  1  ass  i  1  i  ed  ini  oi  mat  ion,  is  a 
sennit  ivity  issue,  wln'i  .'.is  the  intiwuity  ol 
moelianisms  l  li.il  onsuio  anl.hent  ie.ll  ion, 

1  i  usicd  eeiiiiminie.il  ions  pi  oeesses ,  and 
.ie-.Tii.iey  ol  coni  i  ol  data  is  a  ci  ideality 
i  lisue . 

Ci  il  ieality  is-  liel  i  m-.i  in  All!  P  0  L;  —  1 1-  as. 

"  l  lie  1  e.  (U  i  1  i'd  1  c  Vi  ■  1  el  }  -i  i.'t  eel  i  on  ol 

i  esotii  i'os,  whose  eompi  emj  se,  alieiaiioii, 
dost  Micl  i  on,  loss,  oi  lailme  to  im-d 
objectives  will  jeoj'.ii  d  i  zo  mission 

aCcomj’ 1  i  s.hiiu  nt  When  wc  speak  ol 

ei i 1 i ea 1 i t y  ol  a  local  mission,  il  must  b. 
taken  in  l  lie  context  c-i  I)oh  oveiall 
object  ives. 

l.ew]  oi  pictccti.n  against  eoiiipi  onn  sc 
is.  cTiltiliicnsut  at  e  with  the  lnhUlii.i;  ion 
sennit  ivity  (gem  l  a  1  1  y  havin.j  yl.bal  .is.ci  Iona 
t  ci  in  mission  imi’l  Is.il  ion:;)  .  ’lhe  value  .'1 
pi  OLe.'t  ion  against  loss  el  inlemily  oi 
denial  m  n-ivio-  t  lin  al  is  comiiuTisu l  at  e  w-iti: 


the  mission  that  might  not  be  accomplished 
and  has  intent,  sho:  t  term,  local 

implications  (when-  local  pet  tains,  loj 
example,  to  two  p.ut  ies  attempt  ing  to 
common  i  cat  e  oi  to  operations  at  looted  by 
lesouice  un.ivai  J  abi  1  i  ly  1  . 

The  Ttuslid  base  (system  oi  component 
wlii'K'  a  eompul  ei  is.  usually  a  component  )  may 
consist  ot  median  i  sms  to;  belli  sensitivity 
pjotoetion  and  ciiticality  pt  ot  cot  ion, 
liowevet  the  degiee  ol  pioLoetion  ol  the  two 
might  dii  lei  .  In  cel  lain  eas.es,  1  lie  same 
mechanism  can  lie  used  toi  belli  object  ives 
while  in  otliei  eases  distinct  mechanisms  must 
be  ineoiporoted. 

In  ciiticality  ('rot  eel  i  on  moch.ni  i  sms , 
detection  and  iccoveiy  become  mote  applicable 
than  they  ate  in  sensitivity  |  rot  eel  i on .  In 
tact,  these  may  be  mot?  impel  1  am  (and 
m  t  .lnily  mote  piaelical)  than  icsi  stance. 
When  a  ciisis  oi'i'ui :  s,  tlieie  may  bi-  a  t  oiidonoy 
to  t i eat  sensitivity  mote  lightly  to  enhance 
opei at j una 1  know! eye  and  llo.xibility  (o.g., 
I  el  casing  data  I i om  net  mall y  pioteeted 
intelligence  sovit  cos  tot  ope  i  at  ion.il 

decisions).  liowevet,  in  gonotal,  dining  a 
ciisis,  exit  ieality  becomes  i  net  eat;  i  ng  1  y 
i mpoi  t  ant  . 
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that  might  belli  1  the  mis.:;  ion,  taking  into 
account  icguiiod  opoj.it  ional  capability  ami 
pi  t  i-nl  ial  thii-at  .  Specific  opei  at  ions  ami 
opoi  ai  ional  ly  ci  it  i  c.i  1  asset  s  must  be 
ident  ilted.  Tlieii  impoitanoe  to  the  mission 
and  tlieii  necessity  in  mission  aceomp  1  i  shine  nt 
ate  la. 'tins.  ]i  has.  been  suggest  mi  at  the 
Now  Oi  leans  Wot  ksliop  |  1]  that  inlctmal  models 
bo  used  to  aceomp] i sh  this,  namely  mission 
model,  tlne.it  inode  1,  lesoutiVS  model,  and 
1 t I e  eye  to  modi  1  , 


In  a  foi  ilia  ]  integrity  mode)  (  1  1  oin  niba 
( 4 )  )  i  pi  ole-el  ion  level  di Iters  1 1  oin 
sensitivity  ns  loilows:  Wlici  e  the  object  Is 
dma,  then.  is  no  lead  access  lest  lift  ion  to 
individuals  at  1  own  levels.  liowovei  ,  a 
subject  must  dominate  the  object's 
ciiticality  1  eve  i  in  oidm  to  ot  i  g  i  ii.it  c  oi 
mod  i  J.y  the  data.  In  the  cane  ol  pi  oci  sSis. 
t  lie  invokin'!  subject  must  dominate  the 
Ciiticality  level  el  the  piOOess.  hib.i 
pi uposed  that  usei s  and  data  m  njiiui i no  l i om 
t  hem  cat  l  y  a  set  ot  ci  i  t  i  ca  i  i  t  y  at  t  i  i  bat  e 
such  that  data  may  be  moved  only  to  sue  net  s 
(humans  oi  processes)  bearing  an  equal  ci 
iuwer  level  . 


APPLICABILITY  OF  THE  ORANGE  BOOK 

The  Do!)  Ti  listed  Comput  ej  Syr.  t  cm 
Evaluation  t'literia  (Oi  anno  Dock)  was 
developed  loi  us-;  in  evaluating  t  i  ust  ed 
commercial  component  s  and  as  guidance  tin  t  he 
development  and  ovaluat  i  ei:  ol  t  i  list  ed 

computet'  system:;.  These  nit  eiia  ai  e 
neccssaiy  in  application  to  networks  aim 
d  i  st  v  j  billed  systems,  but  air-  net  sui  1  icienl  . 
Certain  terms  and  concept s  (e.g.,  user  and 
system)  must  be  i  ei  nt  oj  pi  et  led  lo  adapt  t.o 
the  changing  t  echno  1  og  i  os  .  Other  issues 
i nclude : 

o  The  i  p.ta  l  connect  ed  nm  1 1  i -syst  em  problem 
is  not  adequately  addressed  in  the 
Ot  ange  Hook 

o  A  logical  way  to  deal  with  t  he 
complexity  or  distributed  systems  is  to 
divide  t  Item  inti*  mnnaqnable  pieces, 
addies.-;  security  tor  each  et  the  pieces, 
and  t  t-.on  address  the  stonily  issues 
involved  in  connecting  trusted  pieces 

o  The  importance  oi  integrity  a ad  denial 
o:  service  t  lit  eat  s  to  networks 

o  By  treating  sensitivity  ana  erit ica) it y 
as  two  separate  issues  i.v  lie)  rove  that 
over  a  range  of  system  i  nip  I  ement  at  ions, 
a  far  more  cost  elloetive  anpr oaoh  to 
netwetk  security  e.ci  lie  achieved. 

We  see  much  commonality  between  t he 
protection  ci  iter  in  1  oi  an  A  division  Joi 
both  criticality  and  sensitivity,  since 
vu 1 norahi Jit  ies  and  mechanisms  have  been 
previously  encountered  by  developers  through 
Orange  Hook  adherence.  Many  systems  have 
been  developed  with  some  er it  ieal it  y 
protect  ion  median  i  sms.  beyond  that  required  by 
the  Orange  Book  .  Oi  1  t  he-Slol  1  components 
have  not  boon  evaluated  again  ;  a  ei  it  ieal it  y 
criteria,  but  they  may  st  ill  be  valuable-  in  a 
criticality  role. 

To  assist  in  arch i t ect  in  a  1  definitions, 
we  developed  a  5t  rawnun  Trusted  System 
livaluat  ion  Criteria  (an  augmented  Change 
Hook) ,  whore  the  sensitivity  level  can  be 
specif  i  ed  as  beiore,  implying  specif  ic 
median i sms  and  levels  ot  assurance  (Figure  ?, 
fro:, i  1 1)  ]  )  .  Our  approach  allows  independently 
determining  the  criticality  level  required 
(Figure  3)  where  the  C  level  concent r at cs  on 
ai t  ack  oot  ect  ion,  B  deals  with  dot ect  ion  and 
recovery,  and  A  specifies  median i sms  and 
assurance  loi  resistance,  detection,  and 
recover y . 


1  ipurc  2. 

Trusted  S) Mem  i  valuation  Oilci.i.  Scn\ih\  ;l\ 


l  imin'  3. 

Tinsted  System  I \ a lu.it ion  t’liteii.r  (Tilie.ilily 


The  idea  ol  eemplc!  ■-  and  leimal 
ci  i  t  i  ca  1  i  t  y  pi  at  eel  ion  is  now  and  uiit  i  i  ed,  at 
least  in  t  lie  ceiumaiid  and  cent  rot  environment  . 
Wo  suspect  that  din-  to  t  ho  opposing  nature  et 
the  oril  ic.il  i  l  y/sensi  t  l  v  i  t  y  duality,  Al/A 
cer t  i 1 i cat i ons.  Jot  example,  will  be 
t  echnol  eg  i  e.i  1  1  y  e'lia  1  leng  i  ng  .  Hy  way  oi  an 
example,  in  tin-  sensitivity  policy  we  do 
not  want  d.,t  a  l  lowing  1 1  cm  a  higher  level 
to  a  lower  level.  In  a  ciiticality  policy, 
f low  is  all  owed,  but  modi t i cot  ion  is  not  . 

DECOMPOSITION 

Evaluation  ol  systems  that  include 
networks  has  three  equally  important  parts: 
evalunt  ion  ol  externally  visible  inti-i  faces, 
evaluation  of  the  ititern.il  components,  and 
ovaluat  ion  of  the  way  in  which  tin-  component s 
have  been  int  ei  connect  ed  .  Tin-  Ti  List  ed  System 
l!ase  must  be  well  deliiu-d  and  have  well 
Specified  interlaces.  It  must  include  (depend 


our  the  Trusted  It. iso  of  the  component  s  and 
the  Trusted  Base  previously  established  lor 
network  host  systems.  Note  that  this 
approach  has  made  it  unnecessary  to  precisely 
tiOlitii  either  processor  or  networks  in 
gene i a  1  . 

The  Orange  Hook  assumes  the  system  is 


monolithic,  with  a  single  security  policy. 
What  is  required  in  a  distributed  system  (the 
system  equivalent  tc  the  Trusted  Computing 
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Olivo  i  In-  syst  cm  is  del  iin-,1  by  t  I)/,A, 
“1‘  i  ity  what  is  imriii.il  to  the 

■  i  ; '  1  'll'  arui  wli.it  in  oxti'i  n.j)  Anti  i  lit  oi  1  ,k-cs 

P*'1  ■  llio  syst  r:«  seout  ity  policy  must. 

*■  °VC1  All  Oi  wll.lt  iS  3  lit  I'J  11,1  ]  ,  |  ’  1  11;,  till’ 

o.\t  r  t  n.i  1  i  lit  i -i  t  .lore  .  Tliii;  concept  is  simile' 

to  t  In1  Oi  .iii-jt-  book's  use  ol  jt  i  nt.it  y  o.xtciti.i! 
nil  oil. ico  as  a  lmm  in  "ur-et  .  "  in  out  Ti  list  ed 
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subject..-."  th.it  ni.iy  1.. 

(o.  g  .  ,  hosts),  n,  t  ;  ks., 
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Tlic  fJtaii  iiy  policy  naj.si  io-.jit  .-it>  c.u  h 
of  these  external  subjects.  Access  com  1  ol 
li. II'.  Ay  be  used  to  dot  oi  mi  no  wh.it 
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Now  WO  look  at  SOCHI  ity  policy  mom  t  hr 
system  level .  At  this  level  it  must  bo 
assured  that,  air  component  policies  am 
suppoitod  t  In  on  it. net  the  system  (incl  tunny 
Jiia  that  eventually  Aie  passed  bm  wren 


components  that  do  not  interface  directly). 
Further,  there  may  be  policy  dictated  at  the 
system  level  that  is  over-and-abovc  the 
policy  that  exists  at  the  individual 
component  level  and  it  must  be  ensured  that 
policy  is  supported.  Finally,  there  exists  a 
policy  at  the  system  level  as  to  its 
interface  with  the  outside  world,  and  it  must 
be  ensured  that  this  system  level  policy  is 
supported  by  the  components  that  interface 
with  the  outside  world  (e.g.,  external 
subjects) . 

When  a  component  is  upgraded, 
decomposition  can  be  used  to  reduce  network 
reaccred i tat  ion  costs.  Decomposition  can 
also  bo  used  when  subsequent  expansion 
(components) ,  concatenate  ion  (two  or  more 
systems  plus  a  gateway),  and  extension 
(addition  of  protocol  layers  beyond  those 
presently  implemented;  of  the  syscem  occur. 


SENSITIVITY  AND  CRITICALITY  THREAT 

An  excellent  discussion  of  sensitivity 
threat  and  mechanisms  can  be  found  in  Voydock 
and  Kent  [6j.  In  studying  sensitivity  and 
criticality  threats,  it  is  disc  vered  that 
they  differ  significantly  (see  Figures  5,  6, 
and  7).  Treating  sensitivity  and  criticality 
separately  may  have?  an  economic  advantage  in 
that  when  data  are  stored  and  being 
communicated,  their  sensitivity  can  be 
protected  with  encrypt  ion .  Once  that  is 
accomplished,  we  can  address  criticality. 


PROTECTION  MECHANISMS 

The  mechanisms  employed  against 
sensitivity  and  criticality  attacks  depend  to 
a  great  degree  on  the  protection  environment 
afforded  by  physical  protection,  and  the 
clearance  ana  access  controls  in  place 
(Figure  B) .  If  encoding  is  used  as  a 
mechanism,  the  distance  (link  or  node)  must 
be  determined,  or  that,  part  of  the  total 
system  ovei  which  it  is  employed.  Finally, 
although  resistance  is  the  primary  choice  for 
sensitivity  protection,  detection,  as  well  as 
recovery  must  aKso  be  considered  for 
criticality  or  for  the  protection  of  the 
integrity  of  sensitivity  mechanisms. 

Sensitivity  mechanisms  are  generally 
known  so  are  not  itemized  here.  For  this 
paper,  it.  is  important  tc  identify  mechanisms 
employed  against  the  critical  icy  throat. 
These  are  presented  in  Figure  9,  itemized 
according  to  whether  detection,  iccoveiy,  or 
resistance  is  the  objective. 

SECURITY  CONSIDERATIONS 

Traditional  socin  ity  factors  considered 
in  monolithic  compute!  systems  also  apply 
when  developing  a  distributed  security 
architecture.  In  addition,  researchers  arid 
practitioners  .in  network  seoui  ity  have 
identified  several  factors  that  must  be 
addressed  il  we  are  to  achieve  an  acceptable 
solution  to  the  network  security  pioblein. 
This  section  ic views  those  factors. 
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Figure  5  Sensitivity  Attacks 
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Figure  6.  Criticality  Attacks 
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Figure  7.  Attack  Characteristics 
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Figuie  K.  Mechanisms  in  (Icneial 


Figure  9.  Ci  ideality  Mechanisms 


complexity  that  must  be  considered  in  access 
control.  In  the  extreme,  each  individual 
user  must  know  the  identity  and  access 
characteristics  of  each  of  the  ettv  users 
(including  himself),  hence  the  name. 

We  have  historically  performed  document 
access  control  based  on  a  so  called 

hierarchical  N-squared  system.  At  an  office 
level  each  person  must  ; now  the  authorization 
of  each  person  in  that  office  because  they 
are  in  close  proximity.  Documents  are  passed 
between  offices  through  a  local  security 
officer.  At  higher  or-ganizat icnal  levels, 
documents  are  again  passed  between  organiza¬ 
tional  security  offices.  At  an  agency, 

corporate,  or  service  level,  both  documents 
and  security  clearances/authorizations  are 
passed.  At  a  national  level,  clearing 
agencies  exchange  information.  That  is,  an 
N-squared  p’ohlcm  is  addressed  at  each  level 
of  the  hierarchy,  but  only  with,  the  elements 
at  that  level. 

Bridges  ana  gateways  can  link  networks. 
Networks  or  linked  internets  can  connect 
individuals,  organizations,  or  agencies.  As 
a  starting  point,  information  can  be 
controlled  in  the  historical  way.  However, 
the  power  of  data  processing  allows  the 
number  of  hierarchical  levels  to  lie  reduced 
and  perhaps  eliminated  completely,  thereby 
dealing  with  the  N-squared  problem. 

The  Cascading  Problem 

The  networking  oi  systems  introduces  the 
cascadir.j  problem  (sec  [/)),  wnicii  is  i.iie 
increase  in  exposure  (the  range  between  the 
highest  classification  of  ta  and  the  lowest 
user  clearance)  in  i ntorconnected  systems. 
For  example,  if  a  TOP  SKCR1  T/SF.CRET  system 
passes  only  SECRET  data  to  a  SECRET/ 
CONFIDENTIAL  system,  the  TOP  SECRET  data  has 
now  been  exposed  or  contaminated  at  the 
CONI' I  DF.NT1  Ah  level  instead  of  just  the  SECRET 
level.  As  more  and  more  interconnections  are. 
made,  in  general,  the  highest  level  will  be 
exposed  at  the  lowest.  ievel  .  Therefore, 
either  all  high  level  data  must  he  protected 
at  a  high  ( A 1  or  B3)  protection  level  or  more 
secure  (but  less  flexible)  modes  of  operation 
(u.g.,  dedicated  or  system  high)  must  be 
used . 

Tire  Security  Policy  Problem 

For  each,  of  the  entities  at  each  ol  the 
sennit  i  v  j  t  y  and  criticality  levels  in  t  lie 
hierarchy,  different  policies  might  exist 
(primarily  because  of  diflcre.it.  threat, 
mechanisms,  and  objectives).  For  a  trusted 
base  (or  the  u.ut  rusted  protection 
oqui valen: ) ,  no] icy  is  a  statement 
(mathematical  or  formally  written)  of 
security  motivated  constraints  (such  as 
discretionary  and  mandatory  access  controls) . 
These  are  the  constraints  to  be  placed  on 
the  modification  and/or  dissemination  of  data 
(including  control  data);  the  initiation, 
control,  or  termination  of  processes;  and/or 
the  assignment  or  use  of  system  resources. 
Policy  mapping  (see  [8]  for  examples  ol 
policy  mapping)  is  the  establishment  of  a 
common  interconnection  nul  h:y  between  two 
communicating  cut  it  n  s,  each,  with  inherently 
different  policies.  It.  identifies  legal 
communications,  con-muni  cut  ions  const  mints. 


required  labels,  required  t rans f or  mat i on  of 
labels  from  t.he  form  used  by  the  sending 
system  to  that  used  by  the  receiving  system, 
and  an  agreement  as  to  mechanisms  to  be  used 
and  their  placement  in  the  the  communicating 
systems . 

Security  Model s 

As  discussed  by  Crosland  and 
Schnackenbei g  [91,  the  distribution  of 

security  funct  ions  and  features  across  a 
network  complicates  the  system  aesign  and 
formal  specification.  In  centralized 
systems,  TCB  requests  are  mediated  by  a 
single  component,  and  thus  can  reasonably  be 
represented  by  a  single  state  transition. 
However,  for  a  network  the  trusted  base  is 
distributed  and  disjoint,  so  that  actions  at 
one  trusted  base  interface  affect  remote 
trusted  base  state  and  remote  trusted  base 
interfaces.  For  example,  when  a  host  or 
terminal  user  requests  a  connection  for  a 
session,  the  local  trusted  base  software 

coordinates  with  the  remote  trusted  base 
supporting  the  destination  device,  and 
possibly  with  network  management  to  determine 
if  the  session  is  authorized.  The  states  of 
two  or  three  trusted  bases  are  changed  as  a 
result  of  a  new  session  being  created  ana  the 
session  creation  event  is  visible  at  the 
external  interfaces  of  two  trusted  bases. 
Thus,  a  single  TCB  request  can  cause  the 
distributed  Trusted  System  Base  ( TSB )  to 

undergo  multiple  state  transitions.  There 
are  two  approaches  that  can  be  used:  a) 

ignore  the  concurrency  and  distribution  of 
fun-  tiuns,  and  ti eat  state  transit ierr.  as  if 
they  all  occurred  atomically  or  b)  describe 
the  interaction  bet. ween  the  remote  TCBs . 

We  have  taken  the  latter  approach  with  a 
hierarchical  modeling  methodology.  First, 
mode)  each  elementary  component  using  the 
techniques  developed  for  centralized 
systems.  Then  model  a  system  composed  of 
components  dealing  with  only  the  subjects  and 
objects  visible  in  the  external  communica¬ 
tions.  Reducing  the  corn)  lexity  allows 
modeling  state  transitions.  When  the  system 
itself  becomes  an  elementary  component,  this 
process  is  repeated.  Mechanisms  similar  to 
deadlock  avoidance  in  "association" 

mechanisms  assure  the  absence  of  mutuilly 
conflicting  secui it.y  state  transitions. 

Covert  Channels 

The  covert  channel  analysis  problem  is 
also  discussed  in  Crosland  and  Schnackenberg 
I 9J  .  In  a  stand-alone  system  the  covert 
channels  tend  to  be  between  processes  under 
the  control  of  an  operating  system.  In  a 
network,  hiwover,  there  may  be  few 
interprocess  covert  channels.  This  is  due  to 
the  limited  resources  available  to  processes 
that  reside  within  the  network  servers.  The 
major  covert  channels  are  between  processes 
that  reside  in  attached  hosts  and 
workstations,  and  signal  each  other  using 
network  resources.  Although  tire  network  can 
detect  possible  usage  ol  this,  covert  channel, 
the  network  is  rrot  able  to  reasonably 
eliminate  it.  The  host  along  with  the  host- 
front  end  has  the  responsibility  to  restrict 
access  to  (or  close)  the  covert  channel . 
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Protocol  Is sues 


interference  with  Mission  operations. 


The  International  Standards  Organization 
Open  System  Interconnect  ion  ( I  SO/OS  1)  seven 
layer  protocol  reference  model  (10]  has 
gained  wide  acceptance,  unfortunately 
however,  not  before  the  Government  had 
already  drawn  up  some  very  i i rm  procedures 
for  handling  data  ir:  communications  and 
networks.  The  Doll  lias  made  a  commitment  to 
move  in  the  direction  of  the  seven  layered 
approach  in  its  future  planning  and 
development,  while  at  the  same  time  ISO  has 
begun  to  deal  with  some  of  the  sticky 
problems  that  are  typical  to  the  11  oD 
applications  te.g.,  security). 


Figure  10  illustrates  the  functions 
present  at  various  layers  and  how 
intercommunication  of  these  functions 
actually  takes  place  at  the  next  lower 
layer.  The  higher  level  protocols  are 
present  at  the  communi eating  nodes  where  the 
applications  reside.  The  communicating  nodes 
and  devices  within  the  network  itself 
communicate  to  one  another  through  the  first 
throe  layers. 
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Figui  10.  The  ISO/OSI  Protocol  Reference  Model 

Figure  11  iilustiates  t.  lire  potential 
security  implement at ions  as  proposed  by  the 
ISO  Draft  Security  Model  [11].  Rnd-io--end 
encryption  can  be  accomplished  in  the  nctwoik 
layer  (3),  the  transport  layer  (4),  or  the 
presentation  layer  (6).  If  there  is  a 
choice,  the  higher  t ho  layer,  the  greater  the 
protection.  In  the  protocol  traffic  analysis 
problem,  if  no  mechanisms  were  employed,  it 
would  be  desirable  to  do  the  end-to-end 
encryption  at  the  nctwoik  layer  (3)  first, 
the  transport  layer  (4)  second,  and  finally 
the  presentation  layer  (G)  .  (Note  that  the 
session  layer  (5)  as  defined  by  t.he  l so 
Reference  model  will  not  support  encryption.) 

Network  service  requests  might  very  well 
be  covert  channels  and  therefore  one  would 
want  to  minimize  nctwoik  services  by 
interconnecting  trusted  bases  where  only 
routing  was  inquired  or  enforce  <:  limited 
bandwidth  in  the  use  of  those  services.  The 
IlrafL  OiU  Reference  Model  on  Security 
proposes  the  availability  of  many  network 
services  by  which  a  user  can  employ  security 
or  ignore  it.  This  is  conti ary  to  the  DoD 
idea  ol  having  continuous  security  protection 
mechai i  i  sms  in  force  that  have  minimum 


Figure  12  depicts  an  approximate 
relationship  between  the  ISO  model  and  the 
commonly  accepted  protocols  inherent  to  DoD 
communications.  The  lack  of  strict 
compatibility  of  layers  at  level  3  and  above 
is  illustrated  here,  but  in  fact  varies,  not 
only  in  people's  minds,  but  from  application 
to  application.  Summarizing  the  primary 
differences,  DoD  has  historically  divided  the 
network  layer  into  sublayers  ana  in  addition, 
there  have  not  been  well  defined  layers  above 
the  host-to-host  interface. 
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Tip ure  12.  Doll  Protocols 

The  specific  standards  written  for 

military  use  are  addressed  in  the  third 
column  of  Figure  12.  Tnis  is  a  mixture  of 
civil  standards  and  military  speci f i cat i ons . 
The  military  is  migrating  to  the  civilian 
X.2T;  and  IEEE  892  standards,  while  at  the 
same  time  commercial  versions  of  TCP  and  IP 
exist  in  the  marketplace.  ISO  equivalent 
standards  (illustrated  by  the  far  right 
column)  arc  striving  to  encompass  the 

features  and  characteristics  of  the 
equivalent  military  protocols  while  main¬ 
taining  a  strict  adhor once  to  their  model. 
The  DoD  has  said  that  it  the  ISO  efforts  are 
successful,  DoD  will  eventually  adopt  the  ISO 
.node  i  s . 


AKCHITECTUP-AT  APPROACH 

Based  on  the  s:-  nsit  ivity  and  criticality 
requirements  in  mission-critical  networks. 
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Figure  13.  Protocol  Layer  Choices  in  this  Architecture 
Encoding  Replaces  Physical  Protection 

Cryptography  lias  long  been  a  major 
COMSEC  protection  mechanism  where  it  is  known 
that  physical  protection  cannot  be  provided. 
Today's  VLSI  circuitry  ran  provide  encryption 
protection  that  is  potent. ial ly  transparent  to 
the  transmission  and  r.toi  age  processes,  and 
does  not  impact  performance. 

Further,  application  of  encoding 
encompasses  much  more  than  simple  encryption, 
with  cryptographic  checksums  (seals)  and 
other  mechanisms,  modi f icat ion  and  replay  can 
be  detected.  With  public  key  approaches, 
senders  and  receivers  can  be  authenticated, 
and  even  the  precise  source  of  a  message  can 
be  guaranteed  days  or  years  later. 

Even  within  physically  protected  areas, 
a  strong  mechanism  against  internal  attack  is 
use  of  encoding  for  both  sensitivity  and 
criticality  protection.  Crypto  checksums  for 
criticality  can  be  used  for  all  data  at  all 
times.  Encryption  of  sensitive  data  can  be 
employed  at  all  times  except  during 
computation  on  the  data  or  its  human 
input/output . 

Such  emphasis  focuses  the  burden  on 
covert  channel  elimination  and/or  protection 
and  detection  mechanisms,  since  such  an 
encoding  approach  for  sensitivity  requires 
that  certain  levels  of  protocol  remain  in  the 
clear  . 

Figure  1 A  shows  cur  architecture  1 
approach  to  networks,  using  these  concepts. 
To  solve  the  sensitivity  problem,  mission 
data  are  encrypted.  To  solve  the  criticality 
problem,  all  data  arc  encoded  using 
cryptographic  checksum  and  authentication. 
The  covert  channel  problem  of  data  leakage 
through  header  information  is  addressed  in 
the  host  systems  rather  than  in  networks. 
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Fifiurc  15.  Distributed  Security 
Distributed  Security  Meehan i sms 

Figure  IS  illustrates  an  extension  to  an 
important  concept  developed  for  the  Blacker 
program  in  which  elements  of  the  security 
systems  are  themselves  nodes  on  the  network. 
In  the  Blacker  approach  [12]  there  is  a 
front-end  node  for  each  of  the  system  hosts 
and  internetwork  gateways,  and  in  addition 
there  are  nodes  for  a  security  monitor 
position,  a  central! rod  key  distribution 
function,  and  a  central  identification/ 
authentication  database. 

We  have  added  additional  functions 
including  an  upgrnde/aowngrade  position  to 
deal  with  high  risk  communications  and  to  act 
as  a  resource  for  use  between  nodes  of 
differing  security  policies.  Also,  a  netvoik 
control  function  establishes  secure 
communication  through  gateways  and  across 
network  bridges.  Although  shown  in  the 
figure  with  the  secure  front-end,  all 
elements  depend  on  a  hand-hold  start / restar f 
module  when  first  coining  up  on  the  network  or 
when  being  removed,  so  security  is  not 
violated.  This  was  another  important  concept 
implemented  by  the  Blacker  program. 

Distributing  these  capabilities  allows 
expansion  of  the  network  at  minimal  security 
cost  and  impact.  Backup  security  functions 
are  facilitated,  since  each  capability  can 
exist  redundantly  on  the  network.  It  also 
allows  adaptation  to  the  load,  for  example, 
where  several  upgr ade/oowngi ado  monitor 
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positions  can  exist  to  Keep  up  wjtn  trie 
traffic  in  a  high  risk  envi ronment . 

Multi-Risk  I  nt  ernet  Co  inmuni  cat  ion 

In  our  proposed  architecture  we  needed 
to  reduce  the  risk  of  interdomain 
communications  where  high  exposure  and/or 
high-risk  connectivity  potentially  exists.  A 
concept  was  proposed  in  which  three  modes  of 
connectivity  are  established  and  supported  by 
the  access  control  function  (soe  Figure  16) : 

o  A  direct  trusted  exchange  to  low  risk 
domains  controlled  only  by  the  access 
control  rules 

o  An  exchange  where  extra-domain  authen¬ 
tication  must  be  performed  manually  by 
the  security  monitor  prior  to  allowing 
an  association  in  medium  risk 
connections 

o  A  monitored  and  verified  exchange  by  a 
manual  (human)  guard  in  an 

upgrade/downgrade  monitor  position  for 
high  risk  connections 

•  Assign  Domain  Vulnerability 

•  Adaptive  Mechanism  Based  on  Trust 


Moure  16.  Multi-Risk  Internet  Communication 
Association  Level  Re r vices 

In  Blacker,  once  data  are  delivered  to 
the  host,  protection  ceases  to  exist  unless 
provided  by  the  host.  We  have  proposed  an 
approach  in  our  architecture  that  has,  at  a 
minimum,  the  Blacker  level  of  protection,  and 
for  sensitivity  and/or  criticality, 
protection  all  the  way  to  the  device 
interfacing  with  the  user.  This  association 
level  protection  (Figure  17)  piovides  key 
distribution  foi  sensitivity  encryption, 
criticality  encoding,  identification,  and 
authentication  light,  up  to  the  mi  ci  oproccssor 
that  inlet  faces  with  the  uset ,  assuming  the 
appropi late  cncipheiing  hardware  is  present. 
A  communication.  though  initiated  through  a 
host,  can  be  protected  liom  that  host  and  its 
other  users.  Associated  chips  and/o: 
algorithms  must  be  contained  in  the 
microprocessor.  All  security  services 
(security  monitor,  identification  authent  i- 
cat  ion,  Key  distribution,  etc.)  within  the 
network  become  part  of  this  association  level 
protect i on . 
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Figure  17.  Association  Level  Serviees 

SUMMARY 

The  proposed  approach  to  no  work 
security  outlined  in  this  paper  separat  t.ne 
sensitivity  requirement  (protection  of 
classified  information)  from  the  criticality 
requirement  (integrity  of  operations  and 
protection  against  denial  of  services)  .  This 
decision  has  resulted  in  the  ability  to  use 
encrypt,  ion  and  covert  channel  protection 
mechanisms  to  solve  the  sensitivity  problem 
in  host  communications  and  data  storage 
problems,  leaving  only  the  criticality 
problem  to  be  addressed.  However,  the 
criticality  problem  can  generally  be  solved 
in  networks  with  detect  ion  and  recovery 
approaches  (existing  primarily  in  the  host: 
protected  domain)  which  are  far  loss  costly 
than  resistive  (formal  model)  mechanisms. 

For  interconnected  hosts/networks,  we 
have  found  that  differences  in  security 
policy  and  different  levels  of  risk  may  be' 
confronted  head-on  by  means  of 
decomposition.  Increased  exposure  must  be 
considered  in  assessing  and  determining 
required  protection  levels.  Interface  policy 
must  be  established  and  supported  both  from  a 
mandatory  and  a  discretionary  perspective. 
The  reference  monitor  concept,  must  be  used  to 
control  access  at  the  network,  component,  and 
individual  user  levels. 

We  have  proposed  architectural  concert  p 
for  computer  networks  that  emphasize 
standardization,  shared  functions,  and 
Opel  at i on  with  planned  networks.  Our 
solution  uses  end-t.o-end  protection  for 
criticality  and  sensitivity  with  association 
level  protection  as  an  added  service.  The 
proposed  functions  to  be  performed  (a 
superset  of  Dlatker  functionality)  include 
security  monitor,  identification  authenti¬ 
cation,  key  distribution,  network  control, 
upgrade/  downgrade,  and  star  t.  /  i  est.ai  t  . 
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A  SECURITY  MODEL  AND  POLICY  FOR  A  MLS  LAN 
I'ctcr  Loscocco 

Office  of  Research  ami  Development 
National  Computer  Security  Center 


I.  BACKGROUND 

The  multilevel  secure  local  area  network  (MI is  LAN) 
to  which  this  security  policy  ami  model  apply  is  a  bioadhnnd 
cable  bus  l.AN  that  uses  T inns  mission  Control 
Protocol/Intcrnct  Protocol  (TCP/IP)  and  Carrier  Sense 
Multiple  Access  (CSMA/CD).  The  LAN  is  capable  of 
having  hosts  that  range  from  single-level,  untrusted  machines 
to  MLS  systems  with  classified  and  compartmcnlcd  data. 
Every  host  on  the  LAN  will  be  connected  to  the  bus  via  a 
Bus  Interface  Unit  (B1U). 

Tire  LAN  is  still  only  in  the  design  stage.  As  (he 
design  changes,  the  security  policy  or  model  may  also  tequire 
changes.  Both  were  written  with  this  in  mind  and  should 
be  flexible  enough  for  most  situations.  As  it  stands  now, 
the  model  Goes  not  totally  describe  some  aspects  of 

communications  on  the  LAN.  These  shortcomings  have  been 
noted  and  will  be  corrected  in  future  versions. 

II.  SECURITY  POLICY 

The  MIJs  LAN  will  implement  a  security  policy  based 
on  the  Department  of  Defense  (DnD)  Scemity  Policy  [  I  ]. 

That  policy  states  that  a  person,  or  machine,  may  not  be 

granted  access  to  classified  (lain  unless  that  person,  or 
machine,  lias  the  proper  security  clcaiancc  and  has  a  need  in 
know  that  data.  There  arc  also  provisions  for  special 

handling  restrictions  (or  caveats)  to  be  added  to  data,  these 

restrictions  must  be  obeyed  whenever  the  data  is  accessed. 

In  the  context  of  the  MLS  LAN,  this  policy  pcitalns 
to  the  IUU  sending  and  receiving  a  packet.  All  data  on  the 
LAN  is  transmitted  in  the  foini  of  a  packet.  A  packet 
contains  the  data  to  be  communicated  as  well  as  dial  data 
needed  to  deliver  it.  This  includes  everything  from  addresses 
and  other  header  information  to  the  security  label.  There 

arc  five  basic  rules  the  LAN  must  enforce  to  assure  the 
t)oD  policy  is  followed. 

Rule  I:  Packets  on  the  LAN  must  be  piopcrly  labeled 
to  reflect  their  security  level. 

Rule  2:  A  rtlU  may  not  transmit  a  packet  unless  it 

is  authorized  to  do  so. 

Rule  3:  A  RIU  may  not  deliver  a  packet  to  a  host 

unless  it  is  authorized  to  do  so. 

Rule  4;  Packets  dclivercdcd  to  a  host  must  not  have 

been  altered. 

Rule  5:  All  security-related  events  must  be  logged  to 
provide  an  audit  ttail  of  any  security 

violations  that  might  occur. 

Rule  I  states  that  all  packets  must  have  a  security 
label  while  they  are  within  the  security  perimeter  of  the 
LAN.  Within  this  perimeter  arc  the  BIUs,  the  cable  bus 
itself,  and  a  special  host  called  the  access  controller  (AC) 
whose  function  will  be  explained  below  (see  Figure  1).  The 
security  label  must  correctly  reflect  the  packet’s  elassilication 
and  any  compartments  or  handling  restrictions  that  might 
apply.  Clearly,  many  of  the  BIU  and  AC  functions  must 

contain  a  high  level  of  trust. 

It  is  the  jab  of  the  BIU  to  enforce  Rule  I.  Ihc  BIU 
must  always  know  the  certified  level  of  trust  of  the  hosts  to 
which  it  is  attached  It  must  also  know  the  security  level 


of  its  current  connections.  When  the  Bill  receives  a  picket 
from  a  host,  it  will  first  check  the  level  of  trust  of  the 
host.  If  the  host’s  level  of  trust  cheeks,  the  BIU  will  use 
the  security  label  provided  by  the  host.  If  not,  the  BIU 
will  assign  a  label  that  reflects  the  level  of  the  cm  rent 
connection. 

Rules  2  and  3  together  state  that  all  communication 
with  the  LAN  will  Ire  in  accoidancc  with  the  DoD  security 

policy.  Rule  2  prevents  a  BIU  fiom  transmitting  data  from 
a  host  whose  security  level  is  either  too  high  or  loo  low. 

It  also  assures  that  a  packet  from  a  host  only  gets  sent  to 

hosts  who  arc  cleared  and  have  a  need  to  receive  it.  Rule 
3  prevents  a  BIU  from  delivering  packets  to  an  attached 
host  who  has  neither  the  required  clearance  or  need  to 

know.  Furthermore,  this  rule  allows  hosts  tw  have  a 
minimum  security  level  placed  on  them  for  incoming  packets 
and  guarantees  that  packets  arc  only  delivered  to  the  hosts 

to  whom  they  arc  sent. 

A  Bill  can  only  enforce  Rules  2  and  3  if  it  is  able  to 
make  decisions  on  whether  or  not  to  send  a  packet  to,  or 
receive  a  packet  from,  another  BUI  based  on  the  address  of 
that  packet,  its  security  level,  and  the  clearance  and  need  to 
know  of  each  of  the  BIU’s.  The  security  label  of  a  packet 
identifies  its  security  level  and  must  correctly  reflect  the 
packet’s  classification  anil  any  applicable  compartments  or 
handling  restrictions  that  might  apply.  A  Biffs  clearance 
and  need  to  know  arc  determined  from  access  contiol  tables. 

Ihc  access  control  tables  contain  the  mandatory  and 
discretionary  access  control  (MAC/DAC)  |2)  information  toe 
each  BIU  and  BIU  pair.  They  reside  on  the  AC  and  arc 
set  up  and  maintained  by  the  Network  Security  Officer 
(NSO),  the  only  user  permitted  to  actually  sign  onto  the 

AC.  Tire  NSO  is  responsible  for  ensuring  that  each  host's 
entries  in  the  tables  properly  reflect  the  security  levels, 
compartments,  and  handling  restrictions  of  data  that  reside  on 
that  host.  He  is  also  rcs[>onsiblc  for  ensuring  that  the 
tables  properly  reflect  which  hosts  can  communicate  at  what 
levels  to  provide  which  services. 

To  start  communicating,  one  host  (III)  would  send  a 
request  addressed  to  another  host  (H2)  specifying  the  security 
level  and  type  of  connection  wanted  Hi’s  BIU  will 

recognize  this  as  a  connection  request  and  reroute  it  io  the 
AC.  Rased  on  the  .access  control  tables,  the  AC  will 
determine  whether  the  connection  should  be  approved.  HI 


figure  i:  security  perimeter 
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is  notified  if  the  connection  is  not  in  accordance  with  tin 
MAC/PAC  policy,  and  112  is  nut  contacted  If  t'u 
connection  is  in  accordance  with  the  policy,  howcvci,  the  AC 
sends  the  reciucst  to  1 12  for  appiovnl  or  disapproval.  112 
then  sends  either  a  connection  acceptance  Or  icjcction 
adihcsscd  to  III.  However,  112‘s  HU)  reunites  (his  hack  to 
the  AC  If  the  connection  is  to  be  o|>cncd,  the  AC  logs 
the  o|icning  in  a  table,  notifies  HI,  and  instructs  the  two 
involved  HIU's  to  set  their  current  connection  status  to 
icflcct  the  proper  hosts  and  levels. 

The  security  of  the  connection  now  tests  with  the  H1U. 
The  AC  is  not  contacted  again  until  the  connection  is  closed 
or  a  sccuiity-rclcvant  event  occms.  A  packet  reaching  a 
HIU,  either  from  one  of  the  hosts  or  the  LAN,  is  accepted 
oi  rejected  accoiding  to  the  levels  of  the  connection  as  set 
by  the  AC.  In  this  way,  the  LAN  guaianlccs  that  only 
authotized  packets  enter  and  leave  the  sceuiity  perimeter. 

Kulrs  2  and  3  cannot  lie.  piopcily  enforced  without 
Rule  4,  and  both  depend  on  communications  wiih  the  AC. 

It  is  imperative  that  these  packets  not  be  tampered  with 
because  unauthorized  connections  could  otherwise  occur. 
Fortunately,  Rule  4  can  be  enforced  using  the  piojic] 
authentication  and  encryption  techniques. 

Rule  5,  strictly  speaking,  will  not  incicasc  the  security 
of  the  LAN.  Rather,  it  is  included  to  increase  the 
confidence  that  the  LAN  is  secure  and  the  probability  that  a 
security  breach  will  be  detcc  ed  and  the  responsible  partyfics) 
identified. 

lire  auditing  capabilities  of  the  LAN  will  l>c  in  the 
m' '  and  the  AC.  The  BIIJ  will  report  to  the  AC,  and  the 
i.  mation  will  be  stored  there  for  later  review  by  (lie 
NSO. 

III.  SECURITY  MOD  FI . 

This  model  is  a  mathematical  description  of  the  secure 
operation  of  the  MI-S  LAN.  A  model  of  the  LAN  must 
include  three  separate  things:  a  BID,  the  AC,  and  the 
communications  between  a  collection  of  HIU’s  and  the  AC. 
'Flic  operation  of  the  LAN  is  saitl  to  lie  secure  if  the  five 
rules  given  above  arc  being  enforced  at  all  times. 

The  model  is  in  two  parts.  The  first  part  introduces 
some  epts  and  functions  needed  to  mathematically  restate 
the  n.  ;,ivcn  above  and  ultimately  docs  so.  Some  of  the 
concr  'ere  borrowed  from  the  model  specified  by  the 

World'  Military  Command  and  Control  System 

(WWM  in  "The  Formal  Model  for  Secure  Data 

Distribu  in  the  WWMCCS  Information  System  (W!S)."[31 
These  concepts  have  been  modified  to  reflect  the  actual 
differences  between  the  operations  of  a  system-high  network, 
such  as  W if  end  a  truly  multilevel  network  with  hosts  of 
varying  sesc  :  levels.  The  second  part  of  the  model 
describes  the  i3IU’s  and  die  AC  with  a  system  of 
intercommunicating  state  machines. 

A.  i...„!icmatical  Restatement  of  Security  Rules 

Before  the  rules  can  Ik  stated  mathematically, 
some  definitions  need  to  tie  introduced  The  security  labels 

of  Rule  1  have  to  lie  formally  defined.  Four  functions  arc 

required  to  describe  Rules  2  and  3.  These  functions  arc: 
scnd-packot,  rcccivc-packct,  conncct-oticn,  and  conncct-dosc! 

To  be  complete,  one  must  postulate  the  existence  of  two 
more  functions,  unaltered  and  audited,  that  guarantee  the 

enforcement  of  Rules  4  and  5,  respectively. 

Assume  there  is  a  set,  P,  of  [rackets  which 
contains  all  the  potential  packets  on  the  LAN.  Rule  1 

dictates  that  a  classification  level  must  be  assigned  to  each 

P,  an  'lenient  of  P,  to  identify  its  security  level.  This  label 
can  lx.  desetibed  as  a  3-tuplc  as  follows: 

Level  »  (S,QH) 

where 


S  =  sensitivity  level, 

C  =  compartir.cnled  information  set,  and 

H  =  handling  restriction  set. 

It  is  the  sensitivity  level,  S,  which  indicates  the 
data's  classification.  The  range  of  possible  values  for  S 
come  from  a  set,  LS.  There  exists  a  ranking  function,  R, 
which  places  a  definite  ordering  oil  the  elements  of  LS. 

The  ixissiblc  sensitivities,  as  ordered  liom  lowest  to  highest 
by  R,  arc:  Unclassified  (U),  Encrypted  lor  Transmission 

Only  (LFTO),  Restricted  (R),  Confidential  (C),  Secret  (S), 
Top  Secret  (TS),  and  Program  and  Control  (PROG). 

It  is  the  compartment  set,  C,  that  contains  the 

nced-to-know  access  control  information.  All  possible 
elements  of  C  arc  drawn  fiom  a  scl,  F.C.  Unlike  LS,  this 
set  is  not  hierarchical.  Each  element,  Ci,  represents  a 

compartment  into  which  a  given  data  unit  can  to  be  placed. 

A  null  C  represents  data  winch  is  not  compart mcnlcd. 

The  handling  restrictions  set,  II,  also  thaws  ils 
elements  from  a  non  hierarchical  set,  EH.  As  its  name 
implies,  this  set  contains  a  set  of  restrictions  which  must  be 
adhered  to  when  handling  a  given  data  unit.  As  with  C,  a 
null  H  represents  no  handling  restrictions. 

All  possible  data  security  levels  come  from  what 
is  called  the  Classification  Set  Space,  denoted  C-Space.  C- 
Spacc  is  dciivcd  from  the  three  sets:  ES,  EC,  and  E1I.  It 
is  defined  as  the  Cartesian  produce 

C-Spacc  =  ES  X  r(EC)  X  P(l-H) 

where  P()  represents  the  power  set  or  set  of  all  possible 
subsets  ef  the  respective  sets. 

A  partial  ordering  of  C-Spacc  can  lie  achieved  by 
introducing  the  concept  of  security  dominance.  Given  any 
two  security  labels.  Ex  and  Ly,  such  that 

Lx  =  (Sx,Cx,IIx)  and  Ly  -  (Sy.Cy.Hy), 

Lx  is  said  to  be  dominated  by  Ly  if  and  only  if 

R(Sx)  is  less  th.an  or  equal  to  R(Sy), 

Cx  is  a  subset  of  Cy,  and 
IIx  is  a  subset  of  Hy. 

Let  there  be  a  function,  dcminatc(Lx,  Ly)  where 
Lx  and  Ly  arc  clcnicnls  of  C-spacc,  which  returns  true  if 
and  only  if  Lx  dominates  Ly. 

Let  there  be  two  functions,  labcl(p)  and  s- 
labcl(p.l)  where  p  is  an  element  or  P  and  1  is  an  element 

of  C-spacc,  that  read  a  label  from,  or  set  the  label  of,  a 

packet. 

Several  concepts  and  functions  need  to  be 
introduced  before  scnd-packct,  rcccivc-packct,  connect-open, 
and  conncct-closc  can  be  defined. 

There  exists  a  set,  I),  defined  as: 

B  -  {  h  |  b  is  a  B1U  on  the  LAN  ). 

B  is  necessarily  nonempty.  It  must  at  least  contain  an 
element,  B-AC,  which  represents  the  AC’s  B1U. 

let  there  be  a  function,  id(),  that  returns  a  b, 

an  element  of  B,  which  is  the  Bill  that  executed  the 
function.  This  function  allows  a  B1U  lo  determine  its  own 

identity. 

Two  functions  exist,  mode  and  s-modc,  which  arc 
defined  as  follows: 

modc(b)  -  returns  current  operating  mode  of  b,  an 
element  of  B 

0  if  packet  labels  from  the  attached  host  can 
be  ti  listed 

1  if  packet  labels  from  the  attached  host 
cannot  be  trusted 
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s-modc(b,  m)  -  sets  current  DiU  operating  mode 
b  -  DIU  to  be  set  -  an  element  of  B 
m  -  0  or  1 

0  if  labels  from  host  arc  to  he  trusted 

!  if  labels  from  host  arc  not  to  be  trusted 

A  DIU’s  operating  mode  must  be  either  zero  or  one. 
Authorization  for  s-modc  to  be  executed  may  only  come 

from  the  AC. 

For  cadi  b.  an  element  of  1>,  there  is  an  access 
control  set  (ACS).  ACS's  reside  on  the  AC  and  arc 

uniquely  identifiable  by  b.  flic  ACS  contains  all  of^  the 
MAC  information  that  the  AC  wrll  need  to  determine  if  b’s 

participation  in  a  given  connection  will  violate  the  MAC 
policy.  Mathematically,  an  ACS  is  a  subset  ot  ACS  spare 

denned  as  the  Cartesian  product: 

ACS-space  -  (T  X  AI  X  AI) 

where  T  is  the  set  of  all  connection  types  and  AI  is  tire 

set  of  all  access  intervals.  T  and  A!  arc  defined  as  follows: 

T  -  (  t  |  t  is  a  connection  type  )  and 
AI  -  {  (a!,a2)  |  (al,a2)  is  a  subset  of 
c-space  and  dominatc(a2,  al)). 

At  present  there  arc  only  four  elements  in  T. 

They  are  remote  access,  R;  file  transfer,  F;  mail,  M;  arrd 

control,  C.  Type  C  is  reserved  for  communication  with  the 
AC.  As  the  need  arises,  more  elements  may  be  added 
without  effecting  the  model. 

Hie  components  of  each  access  interval  arc  the 
minimum  and  maximum  security  levels  that  a  packet 
belonging  to  a  particular  connection  may  be  and  stilt  pass 

through  the  BIU.  Tire  second  arrd  third  comiwncnts  of  each 
Clement  of  iliC  ACo  iCpiCSCm  ihe  two  ilucciioiis,  going  out 
of  and  coming  into  the  host,  that  packets  may  flow  through 
a  DIU.  Each  element  of  an  ACS  represents  a  ifferent 

range  of  security  levels  at  which  a  given  host  may  participate 
in  a  connection  of  a  given  type.  In  practice,  the  minimum 
level  of  all  incoming  packets  will  usually  be  (U, (),()). 

Two  functions  exist,  min()  and  max;,),  which  take 

an  access  interval  as  an  argument  and  return  its  respective 
minimum  and  maximum  security  levels.  They  ate  defined  as 
follows: 

if  (al,n2)  is  an  element  of  AI, 

then  min((al,a2))  =  al  and  max((al,a2))  =  a2. 

For  each  b,  an  element  of  13,  there  is  also  a 
discretionary  access  set  (DAS)  PAS's  also  reside  on  the 
AC  and  arc  uniquely  identifiable  by  b.  The  DAS  contains 
alt  of  the  PAC  information  that  the  AC  will  need  to 
determine  i(  b's  participation  in  a  given  connection  will 
violate  the  DAC  policy.  Mathematically,  a  PAS  is  a  subset 
of  DAS-spacc  defined  as  the  Caitcsian  product: 

DAS-spnee  =  (1)  X  T). 

where  D  and  T  are  as  above.  If  a  BIU,  bl,  has  a  PAS 
that  contains  an  element  (b2,t),  discictionary  access  of  type, 
t,  to  BIU,  b2,  could  be  granted  to  bi. 

With  the  ACS’s  and  PAS's,  the  AC  lias  all  of 
the  necessary  access  control  information  to  cnsutc  that  the 
security  policy  is  not  violated.  lire  NSO  must  take  great 
care  in  specifying  the  ACS’s  and  PAS’s  to  insure  that  the 
MAC/DAC  policies  arc  properly  enforced 

Two  functions  arc  defined  to  describe  the  access 
checking  done  by  the  AC  for  one  BIU.  These  functions, 
mandatory-access  and  discrclionnry-acccss,  aic  as  follows: 

niandaiory-ncccss(bl,  type,  aio,  aii)  and 
discrctionary-aeccss(bl,  b2,  ty|>c), 

where 


bl  «  the  BIU  for  which  the  checking  is  Ireing 
done  -  an  element  of  B, 
type  “  the  type  of  connection  in  question  - 
an  element  of  T, 

aio  ~  the  outbound  access  interval  of  the 
conncetion  in  question  -  an  element  of 
Al,  arid 

aii  =  the  inlxruad  access  interval  of  the 
connection  in  question  -  an  element  of 
AI. 

Mandatory- acccss(b,  type,  aio,  "ii)  returns  true  if  and  only  if 
there  exists  an  element  of  b’s  ACS, 

a  -  (t,  (mini,  maxi),  (min2,  max2)), 

such  that 

t  =  type, 

dominate(min(aio).  mini), 
dominated  max  I,  max(aio)), 
dominated min(aii),  min2), 
dominatc(irrax2,  max(aii)). 

Discrctionary-acccss(bl,  b2,  type)  returns  true  if  and  only  if 
there  exists  an  element  in  bl’s  DAS, 

a  =  (b,  t), 

such  that 

b  “  b2  and 
t  -  type. 

Using  manda'ory-acccss  and  discretionary-access,  it 
is  possible  to  more  completely  desetibe  what  is  meant  by  an 
authorized  connection.  A  connection  of  a  given  type  may 
be  authorized  bc'wccn  two  BiUTs  ot  given  access  intervals  if 
the  mandatory  and  discretionary  access  checks  succeed  for 
each  host  A  new  function,  open-ok,  returns  a  true  value 
when  it  is  possible  to  authorize  a  connection.  It  is  defined 
as  follows: 

opcn-ok(bl,  b2,  t,  ail,  ai2), 

where 

(bl,  b2)  is  a  subset  of  B, 
t  is  an  element  of  T,  and 
(ail,  ai2)  is  a  subset  of  AI, 

returns  true  if  and  only  if 

mandatory-aecess(b),  t,  ail,  ai2), 
discrctionary-aeccss(bl,  b2,  t), 
mandatory- acccss(b2,  t,  ai2,  ail),  and 
discrctionary-aceess(h2,  bl,  t). 

It  Is  important  to  note  that  a  return  value  oT  true  here 
docs  not  mean  that  a  connection  has  lx:cn  established 
between  bl  and  b2  but  only  that  such  a  connection  would 
not  violate  the  MAC/OAC  policy. 

A  packet  may  exist  on  the  I. AN  only  if  it  was 
transmitted  through  an  authorized  connection  In  managing 
all  oT  its  host's  connections,  a  BIU  assigns  a  currently 
unassigned  connection  number  to  each  connection  it 
establishes  for  its  Post.  It  is  important  to  note  that  the  two 
IllU's  involved  in  a  connection  may  refer  to  that  connection 
with  a  different  connection  numlrcr.  These  connection 
numbers  arc  dements  of  a  set,  Connections,  denoted  by  UN. 
Each  of  a  BID'S  connections  may  be  uniquely  identified  by 
an  oidcrcd  pair,  (b,  cn),  where  l>  is  an  element  of  II  anil 
cn  is  an  element  of  CN. 

r  et  mere  DC  a  iirnciion  iiew-cmnj,  wticte  1)  is  an 
element  of  B,  that  assigns  an  unused  connection  numl'ci  to 
the  BIU,  b.  This  function  is  used  in  the  o|>cning  of 
connections. 

There  is  certain  information  kept  al  every  BIU  for 
each  possible  connection.  This  includes  the  connection  type. 


the  other  BIU  involved,  ami  the  access  intervals.  The 
following  functions  exist  to  retrieve  this  infonnation: 

ct(li,  cn)  -  returns  the  cuticm  connection  type 

t  :  an  element  of  T  if  the  connection  exists 
NULL  :  if  there  is  no  connection 

eb(K  cn)  -  returns  the  current  BIU  connected  to 

bl  :  an  element  of  It  if  the  connection  exists 
NULL  :  if  there  is  no  connection 

ccn(c,  cn)  -  returns  the  connection  number  used  by 
the  other  BIU 

cnl  :  an  element  of  CN  if  the  connection 
exists 

NULL  :  if  there  is  no  connection 

caio(b,  cn)  -  returns  current  outbound  access 
interval 

ai  :  ar.  element  of  AI  if  the  connection  exists 
NULL  :  if  there  is  no  connection 

caii(b,  cn)  -  tctunis  curicnt  inbound  access 
interval 

ai  :  an  element  of  AI  if  the  connection  exists 
NULL  :  if  there  is  no  connection 

whe.rc 

b  =  the  DIU  in  question  -  an  element  of  B  ami 
cn  =  the  connection  number  in  question  - 
an  element  of  CN. 

Five  functions  exist  to  set  this  connection  status 
information  in  a  BIU.  Fncli  of  these  functions  lias  thicc 

arguments:  the  BIU,  the  connection  number,  and  the 

information  to  be  set.  They  aic  cxccurcd  exclusively  at  the 
request  of  the  AC  and  return  true  if  and  only  if  the 
information  is  properly  stored  The  five  functions  arc 

defined  as  follows: 

s-ct(b,  cn,  t)  -  sets  the  current  connection  type 
b  »  BIU  to  be  set  -  an  element  of  B 
cn  =  connection  number  on  the  BIU  to 
be  set  •  an  element  of  CN 
t  =  new  connection  type  -  an  element 
of  T  or  NULL 

s-cb(bl,  cn,  b2)  -  sets  the  current  BIU 
connected  to 

b  =■  BIU  to  lie  set  -  an  element  of  U 
en  connection  numlicr  on  the  BIU  to  be  set 
an  element  of  CN 

b2  *■  other  BIU  -  an  element  of  It  or  NULL 

s-ecn(b,  cnl,  cn2)  -  sets  the  connection  number 
of  the  other  BIU 

b  «=  BIU  to  be  set  -  an  element  of  B 
cnl  »  connection  numlicr  on  the  BIU  to  be  set 
an  element  of  CN 

cn2  «•  connection  numlicr  on  the  other  BIU  -  an 
element  of  CN  or  NULL 

s-caio(b,  cn,  ai)  -  sets  the  current  outbound 
access  interval 

b  =  BIU  to  tic  set  -  an  element  of  1! 
cn  =  connection  number  on  the  BIU  to  be  set  - 
an  element  of  CN 

ai  =  new  outbound  access  intcival  -  an  element 
of  AI  01  NULL 

s-caii(b,  cn,  ai)  -  sets  the  ament  inbound 
access  intcival 

b  =  BIU  to  lie  set  -  an  element  of  II 
cn  =  connection  number  on  the  BIU  to  lie  set  - 
an  element  of  CN 

ai  =  new  inbound  access  intcival  -  an  element 
of  AI  or  NULL 

NULL  values  indicate  that  the  connection  is  being 
terminated. 


let  there  be  a  function,  set  stale- info(),  that  is  to 
be  used  as  a  convenient  way  to  set  and  reset  the  state 
information  described  above,  Jt  is  defined  in  terms  of  the 
last  four  functions  defined  above  and  L;  executed  exclusively 
at  the  request  of  the  AC. 

Sct-state-infofbl,  cnl,  b2,  cn2,  t,  ail,  ni2)  -> 
true  if  and  only  if 

s-ct(bl,  cn,  t),  s-cl>{  1>1 ,  cnl,  b?.), 
s-ccn(bl,  cnl,  cn2),  s-caio(l>l,  cn,  ail),  and 
s-caii(bl,  cn,  ai2) 

and  if 


t  =  NULL..  b2  = 

NULL,  cn2 

a 

NULL,  ail 

=  NULL,  or  ai2  *= 

NULL  then  t 

= 

NULL, 

b2  =  NULL,  cn2 
and  ai2  =  NULL. 

=  NULL, 

ail 

NULL, 

The  second 

condition  exists  so 

that  all 

of 

the 

status 

information 

is  reset  whenever 

any  part 

of 

(lie 

status 

information 

is  reset. 

The  AC  must  keep  trnci-.  of  all  open  connections. 
When  a  connection  is  opened,  the  AC  records  the  event  by 
entering  all  of  the  pertinent  information  in  the  connection 
table  (CT).  The  Cf  is  defined  as  a  subset  of  Connection- 
space  which  is  the  Cartesian  Product: 

Connection  spacc=(B  X  CN  X  I)  X  CN  X  T  X  AI  X  AI). 

Hie  AC  uses  the  function  add-connection  to 
record  the  opening  of  a  connection  in  the  CT.  This 
function  makes  two  entries  into  the  lable,  one  for  each  BIU 
involved  Both  entries  contain  the  same  information  but 
rearranged  so  that  each  Bill’s  status  information  L  icficcicd. 
The  definition  is  ns  follows: 

add-conncction(bl,  cnl,  1)2,  cn2,  t,  ail,  ai2) 

returns  true  if 

(lit,  cnl,  1)2,  cn2,  t,  ail,  ai2)  and 

(b2,  cn2,  bl,  cnl,  t,  ai2,  ail) 

have  beer,  added  to  tlie  CF.  Hie  reason  that  the  access 

intervals  arc  reversed  in  the  two  tuples  is  that  if  two  Bill's 
are  communicating;  one’s  outgoing  traffic  will  lie  the  other's 
incoming. 

Htc  AC  uses  the  function  del-connection  to  delete 
entries  in  the  CT.  Unlike  add-connection,  this  function  only 
effects  one  entry  in  the  Cf.  When  a  Bill  notifies  tire  AC 

that  it  is  through  with  a  connection,  the  AC  calls  this 
function  to  icmovc  that  Bill's  entry.  this  function  must  be 
called  twice  to  completely  close  a  connection.  del- 
connection(bl,  cnl)  returns  line  if  a  tuple  in  the  foim  of 
(bl,cnl,b,cn,t,ail,ai2)  is  removed  from  the  CF,  where  b,  cn, 
t,  ail,  ai2  need  not  lie  specified.  Since  the  otdered  pair 
(Id,  cnl)  uniquely  determines  one  of  bl’s  connections,  it  is 
unnecessary  to  completely  specify  the  tuple- 

It  is  now  possible  to  define  send  packct()  and 
rcccive-packct().  Both  of  these  functions  return  true  only 
when  their  rcsiKCtivc  tasks  have  successfully  been  completed. 
Tacit  takes  five  arguments  defined  as  follows: 

sli  =  source  Bit)  -  an  element  of  li 
sen  -  source  ItIU’s  connection  number  -  an 
element  of  CN 

db  =  destination  Bit)  -  an  element  of  B 
den  «=  destination  Hill’s  connection  mini  lice  - 
an  element  of  CN 

packet  -  the  entire  packet  being  sent  or 
received  -  an  element 
of  P 

It  is  implicit  in  the  definition  oT  both  functions  that  sb,  sen, 
rib,  and  den  proixnly  reflect  tire  source  and  destination 
address  of  the  packet  they  ate  passed  as  scnaiatc 
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arguments  lor  cosier  reference  atui  understanding. 

Definition  of  scnd-puckcl(sb,  sen,  db,  den,  packet): 

»f  l 

[modc(sb)  »  0  and 

cb(sb,  sen)  -  db  and 

ccn(sb,  sen)  -  den  and 

dominntc(labcl(parkct),  min(cnio(sb,  sen))) 
and  dominatc(max(caio(sb,  sen)), 
labcl(  packet)!) 

or  [modc(sb)  -  I  and 

cl)(sb,  sen)  »  db  and 

ccn(sb,  sen)  -  den  and 
s-labcl( txicket,  max(caio(sb)))] 

or  db  =  'B-AC' 

or  sb  *■  'B-AC' 

1 

Hicn  send-packet(sb,  sen,  db,  den,  packet)  ->  True 
Lise  scnd-packct(sb,  sen,  db,  den,  i>ackci)  ->  false 

Definition  of  rcccivc-packct(sb,  sen,  db,  den,  packet): 

If  [  id()  «  db  and 

unaltcrcd( packet)  and 
[  [cb(db,  den)  =  sb  and 
ccn(«1b,  den)  -  scr.  and 
dominate(labcl(  packet),  min(caii(db,  den)))  and 
dominatc(max(caii(db.  den)),  lahel(  packet))] 
or 

sb  -  'B-AC1 
or 

db  -  ’n-AC’]l. 

then  rcccive-packet(sb,  sen,  db,  den,  | wicket)  ->  Tine 
else  reccivc-packet(sb,  sen,  db,  den,  packet)  ->  false 

whcic  ‘B-AC  is  die  AC's  BID  ami  unaltered  is  tbe  function 
which  returns  (rue  if  and  only  if  the  packet  arrived 
unaltered. 

finally,  it  is  possible  to  define  connect-open  and 
connect-close.  Each  returns  true  when  a  connection  has 
actually  been  opened  or  closed.  Both  functions  arc  defined 
recursively  in  terms  of  each  othc". 

When  opening  a  connection  between  two  Bill's, 
what  actually  happens  depends  on  which  Bill’s  arc  involved 
When  the  B-AC  is  the  lequesting  BIU,  it  generates  a  new 

connection  number  and  informs  the  other  JIIIJ  that  a 

connection  is  being  opened.  The  other  IHU  generates  its 

own  new  connection  number,  sets  its  state  information,  and 
transmits  i's  connection  numltei  in  the  process  of  notifying 
the  B-AC  that  it  is  ready.  The  B  AC  now  has  the 

necessary  information  to  set  its  own  state  information. 
When  finished,  the  B-AC  notifies  the  AC  that  the 
connection  has  been  opened  so  that  the  AC  may  add  it  to 
the  connection  table.  Any  lilt)  wishing  to  open  a 

connection  with  the  B-AC  sends  an  open  request  to  the  11- 

AC,  and  the  B-AC  then  proceeds  as  if  it  initiated  the  open 
request,  following  the  steps  given  above. 

No  BIU  can  go  directly  to  another  BIU  to  request 
an  open  connection.  The  AC,  through  the  B-AC,  must  be 
consulted  for  all  such  requests.  The  requesting  BIU  (hi) 
must  open  a  connection  with  the  B-AC  to  ask  the  AC  for 

permission  to  open  a  connection  10  another  BIU  (l>2)  (foi 
which  hi  has  already  assigned  a  connection  number).  If  the 
AC  denies  the  request,  then  B-AC  closes  the  connection.  If 
the  AC  approves  the  request,  then  B-AC  opens  a  separate 
connection  with  b2  who  is  informed  of  the  hi  request.  If 

b2  rejects  the  request,  the  U-AC  notifies  b!  and  Ixilli 
connections  are  closed.  If  the  request  is  accepted,  hovwcvcr, 
1)2  is  instructed  to  generate  a  connection  number,  set  its 
status  information,  and  report  back  to  the  B-AC.  B-AC 
sends  the  b2  connection  :uiml>cr  to  bl  with  instructions  to 

set  its  status  information  and  report  back  to  the  B-AC. 
Since  they  now  consider  the  connection  between  them  open, 

bl  and  b2  both  close  their  connection  with  the  B-AC.  and 


the  AC  adds  the  connection  to  the  Cl 

In  closing  n  connection,  the  action  taken  also 
depends  on  which  IIILTs  nrc  involved  A  Bill  consideis  a 
connection  .aosed  when  its  half  is  closed.  The  It  AC  closes 
its  connections  by  resettling  its  status  infm  matioii  and 
notifying  the  AC  to  delete  the  connection  liom  the  CP  li 
lias  been  assumed  Hull  the  ollici  BIU  would  initiate  the 
close  of  all  connections  involving  the  11  AC. 

A  BIU  closing  a  connection  with  the  I!  AC  must 
notify  the  11-AC  so  that  insliuctimis  may  lie  issued  to  reset 
the  BIlTs  status.  When  conln  motion  lias  ai  lived  that  the 
other  BIU  has  been  reset,  the  I)  AC  icsels  ils  status 
information  and  notifies  the  AC  to  delete  the  connection 
fiorn  the  Cl.  A  Bill  closing  connections  that  do  no! 

involve  the  11-AC  must  open  a  connection  with  the  11  AC  to 
notify  the  AC  that  the  connection  is  closing,  icsct  its  status 
infoimalion  when  instmeted  to  do  so,  and  close  the 
connection  witli  the  11-AC.  The  AC  deletes  each  half  of 

the  connection  as  it  is  closed. 

The  following  constants  me  used  in  conncct-npcn 
and  conncct-closc: 

B-AC  -  The  AC's  lllll. 

C  -  A  type  of  connection  used  for  contiol 

information. 

Contiol-AI  llic  access  intcival  used  in  a 

connection  of  tyi>c  C. 

SBT-STATE-1NTO  -  Tucket  insti noting  a  lllll 

to  set  its  state  information.  The  state 
information  is  contained  in  the  packet. 

OBEN-REQ  »  Backet  icqnesting  the  opening 
of  a  connection.  The  necessary 

ii'ifwi m. i i i oil  is  lAiiit'iiucd  iii  the  packet. 

Ol’EN-ACK  «■  Backet  notifying  receiver  that 

tlr  proposed  connection  has  lx:cn  accepted. 

OBI  N  NAK  ■»  Backet  notifying  receiver  that 

the  proposed  connection  has  been  refused. 

OBENED  -  racket  notifying  receiver  that  a 

connection  has  been  opened. 

CLOSED  «  racket  notifying  receiver  that 

current  connection  is  closing. 

The  parameters  of  connect-open  are: 

bl  -  bio  requesting  connccl-opcn  -  element  of 
B. 

cnl  -  parameter  in  whiJ-.  connection  number 

for  bl  is  to  bt  remmed  -  element  of  CN. 

b2  -  bin  connect-open  requested  of  -  element 
of  B. 

cn2  “  parameter  in  which  connection  number 

fi  i  b2  is  to  be  returned  -  element  of  CN. 

t  m  type  of  connection  -  element  of  T 

aio  =  outbound  Al  for  bl  (inbound  for  b2)  - 
element  of  Al 

aii  "  inbound  Al  for  bl  (outbound  foi  b2)  - 
element  of  Al 

The  definition  of  conncct-open  follows: 
conncct-opcn(b],  cnl,  b2,  cn2,  t,  aio,  aii) 

/*  Connection  from  the  11-AC  to  any  BIU  */ 

IF  (bl  -  '11-AC') 

THEN 

cnl  ----  ncw-cn(bl) 

scnrl-packct(bl,  cnl,  b2,  cn2.  'SF.T-STAT E-INFO') 
rcccivc-|xickct(bl,  cnl,  b2,  cm2,  'S1H -STATE-INFO’) 
cn2  =  ncw-cn(h2) 
set-state- info(b2,  cn2,  bl,  cnl,  ’C', 

'CONTKOE-AF,  ’CONI  KOI -AT) 
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sem!  ptckcl(h;.  in?,  hi,  on  1 ,  ’OKI  Nl  IV) 

Tcecive-p.u-hcl(b?,  cn2.  Ill,  ail,  TKINLIV) 
scl-5tatc-iiifo(hl,  ail,  !>?,  ai?,  T’, 

TON  1  KOl.-AI’ ,  TON  I  KOI  -AV) 
ndd-conncction(bl,  ail,  1C,  cn?,  T’, 

TON  I  KOI. -AC,  ’('ON  I  KOI  -  AI  ) 

/♦  Connection  fioin  any  HU!  to  the  II  AC  */ 

1,1  SI.  II  (1C  -  ’ll  AC) 

1  11  I  N 

semi  ptehclibl,  ’NUi.l?,  !>?,  ’Nlll.l?.  ’OKfN-RKQ’) 
rcccivc-|\ickcl(bl,  ’NU1  1.’,  I-?,  ’NIM.I?,  ’OITN-Rl’Q’) 
coiincao|'Cit(lC,  I'l,  T\  TONTKOI.-AK,  ’CON l'KOI-Al’) 

i;i2JL  /*  Connection  foi  any  otlici  two  Hill’s  */ 
connect  011011(1)1,  cn?,  ’ll  AC,  cn-l, 

TON  1KOI.-AK,  ’<T>N  I  KOl.-AK) 
sctrd-paekcl(  bl,  cn.?,  ’ll  AC,  civl,  ’OKKN-RIQ’) 
reecivc-psckct(bl,  cn.?,  *|1  AC,  civl.  ’Ol’l.N-Kl  Q') 

II  (  npcil-ok(l)l,  !>?,  t,  ail,  ai?.)  ) 

T1 11N 

conOCCi-opcn(’ll-AC’,  cn5,  b2,  end,  ’O’, 
'CONTKOI.-AK,  TONTKOI.-AK) 
scinl-|xickct(’l!  AC,  cn?,  b2,  end,  ’OKI  N-KI  Q') 

rcccive-packet(Ml-AO’,  cn?,  h2,  aid,  ’Ol’liN  K1Q‘) 
send  picked b?.  end,  ’ll  AC,  cn?,  Kl  SI’ONSl ) 
rcecivc-packct(b2,  end,  'll  AC,  cn?,  RlSI’ONSli) 

II-  (KliSl’ONSK  -  ’OKKN  A(’K’) 

T5 1  i:n 

nil  >=  ncw-cn(bl),  cn?  »  ncw-cn(b?) 
scml  p:ickct(*ll  AC,  cn?,  Ii2,  end,  ’Sl.T-S  TATli-lNI  O’) 
rcceivc-packct(’ll  AC,  cn?,  1)2,  end, 

•si:t-stati:  into-) 

set-stntc-info(li2,  cn2,  hi,  cnl.  t.  aii,  :tio) 
scnd-prckel(b2,  end.  ’ll  AC,  enS,  ’OKRNtlV) 
reeeive-packct(!>2,  end,  ’ll- AC,  on 5,  ’Ol’l  Ni  l?’) 
send-packetCH  AC,  civl,  bl,  cn?,  ’Slil  -S  1  ATI i-lNl  O’ 
rCCeive-packeK’H-AC,  cnl,  bl,  cn?, 
•SUT-STATII-INI-O’) 

set  slate-in lo( til,  cnl.  I'.’,  onA  t.  aio,  aii) 

scnil-pnckeKbl,  cn3,  ’"  AC,  end,  ’Ol’l.Nl  IV) 
rcccivc-packci(lil,  cn?,  ’H  AC,  cnl,  ’Ol’fNl  IV) 
aclil-conncction(lil,  cnl,  l>2,  cn2,  t.  aio,  aii) 
connecl-closc(l)l,  cn?,  ’ll  AC,  civl) 
conncet-closc(lr2,  end,  ’ll-AC,  cn?) 

EiJii: 

conncet-closc(h2,  end,  ’ll  At”,  on?) 
scn(’-pael\Ct(’il  AC’,  civl,  bl,  \'«3,  ’OKI  N-NAK’) 
rcccivc-packct(’ll- AC,  end,  bl.  cn?,  ’OKI1N  NAK’) 
conncct-closcflil  cn?.  ’ll  AO’,  civl) 

list 

scnil-ptcket(Mt  AC,  civl,  bl,  cn?,  ’OKl'N-NAK’) 
receive  packsK’ll-AC,  civl,  bl,  cn.?,  ’OIT.N-NAK’) 
conncct-closc(bl,  cn?,  Ml-AC,  civl) 

The  parameters  of  conncct-closc  me: 

bl  >=  HIU  wishing  to  close  its  ixntion  of  a  connection 
cnl  -  bl’s  connection  number  to  be  dosed 
Ii2  *  Other  PIU  involved  in  connection 
cn2  «  b2’s  connection  number 

The  definition  of  conncct  close  follows: 

conncct-c'osc(bl,  cnl,  b2,  cn'2) 

II  ;iil  =  MV  AC) 
o’llbN 

set  sUltc-iiifo(bl,  cnl,  ’MU1.1,’,  ’Nlil  1.’,  ’NUI  1.’, 
’NUI.l.’,  ’Nlll.l  ’) 
del-coniicclion(bl.  cnl) 

111. Sf  If  (1)2  -  Ml  AC) 
rii'N 

send-packctibl,  cnl,  l>2,  m2,  T1 .OS1.IV) 
reccive-packct(l)!,  cnl,  1)2,  cn2,  ’Cl.OSfU  ) 
send- puckct{ I>2,  cnl,  bl,  cnl,  ’Sf? -STATU-INTO') 
rcceivc-packet(b2,  cn?,  bl,  col,  ’SHT-STA  I  lv  1N1  O’) 
scnd-pncket(bi,  cnl.  b7,  en2,  ’Closin')’) 
uceivc-p.irkct(l)|,  cnl,  1)2.  cn2,  ’Cl.OSr.P’) 


set  statc-inlo(bl,  cnl,  ’NIJI  l.,  ’NUI.l.,  ’Nlil  I., 

’NIU.I..  ’NUI.l?) 
del  coiincction( bl,  cnl) 
connect  closc(l'2,  cn?,  bl,  cnl) 

1.1  SL 

send  packct(bl,  cnl,  b?,  cn2,  ’Cl  .OS I  IV) 
receive -paekct(b!,  cnl,  1)2,  cn2,  TIOSKIV) 
Conncet-opcn(bl,  cn?.  Ml  At  ”,  Civl, 

TONTKOI  -AI’,  TON  I  KOI  - AT) 
connect opcii(b2,  cn?.  Ml  AC’,  end, 

’CON  I  KOl.-AI’,  ’CON  I  KOI. -AT) 
send  packet!  bl ,  n),  Ml  AC,  civl,  ’CI.OSI  IV) 
scnd-packcU  1)2,  cn?,  Ml  At”,  end,  ’Cl  OSl’.IV) 
icccivc-pacKct(bl,  cn?.  Ml  AC”,  cn-l,  *C’l  -ON  I  - 1  >*) 
tcccive-|iackct(l'2,  cn?.  Ml  At”,  end,  ’CI.OSII1V) 
send  packct(’ll- AC”,  cn-l,  bl,  cn?,  ’Sl.T-STATf.-IN]  O') 
send  | v.ckclC ll-AC”,  end,  b2,  cn?,  'SI  1-S  1  ATI'-IN]  O’) 
itvcivc-packcU’H  AC,  civl,  bl,  cn?,  'SVT  STATI'-INl  (?’ 
rcccive-piekct(Mi  AC,  end.  b?.  cn?,  ’SIM  -S 1  A  1  11  INI  O’ 
sct-statc-info(bl ,  cnl,  'NUi.l,*,  'NUI.l?,  ’NUI.l’, 
’NUI.l?,  ’Nlll.l?) 

set-state- in fo( b?,  en2,  'Nlll.l?,  ’Nlll.l?,  ’Nlll.l?, 
’NUi.l?,  ’NU1.1?) 

scndirackct(  bl,  cn?,  ’ll  AC,  end,  Tl.OSLIV) 
scnd-packet(l’2.  cn?,  Ml-AC,  end,  TI.OSI.IV) 
rcecive-pacKct(bl,  cn?,  Ml-AC,  civl,  ’Cl  OSl’.lV) 
rcccivc-packct(l'2,  cn?,  Ml-AC,  end,  Tl.OSlilV) 
dcl-conncclir>n(bl,  cn  I ) 
de!-connection(b2,  cn2) 
connect-close(bl,  cn?,  Ml-AC’,  civl) 
connecl-close(  b2,  end,  Ml-AC’,  end) 


l  et  ilicrc  be  a  set,  V,  which  is  the  set  of  all 

possible  cvcnis  that  occur  on  the  network.  Some  elements 
of  l  would  Ire  things  such  as  owning  a  connection, 

delivering  a  packet,  or  a  new  host  atlded  to  the  l.AN 

Some  of  these  events  aie  security  related  and,  as  such,  need 

io  be  audited.  These  might  oeCui  iii  the  fill’  (an 

improix'ily  labeled  picket  anives  at  the  HIU)  oi  at  the  AC 
(a  connection  request  is  denied). 

let  there  exist  a  function,  scent  ily-rclcvant(e), 
where  e  is  an  element  of  1’.  that  determines  if  an  event  is 

seemity  relevant.  Let  tlictc  also  Ire  a  function,  audit(e), 
that  causes  tire  tiote,  place,  and  involved  panics  of  that 
event  to  Ire  logged  in  audit  files  located  on  the  AC. 

It  is  now  prssible  to  present  mathematical 
conditions  that  must  hold  true  if  the  five  security  tides  aie 
being  enforced.  Stiictly  speaking,  Rule  •!  is  unnecessary 

because  it  can  be  implied  fiotn  Rule  3.  It  lias  been 
included  to  emphasize  the  importance  of  packets  ariiving  at 

their  destination  unaltered.  1  he  live  security  tides  aie  as 
follows: 

Rule  1.  I-’oi  nil  p,  an  element  of  1’,  thcic  exists  an 
1,  an  element  of  C-sptce,  such  that  label(p) 
=  1. 

Rule  2:  lor  any  b,  an  element  oi  H;  cn,  an  element 

of  CN;  and  p,  an  element  of  1’,  b  may 

transmit  p  on  cn  if  and  only  if  send 
packct( b,  cn,  cb(b,  cn),  ccu(b,  cn),  |))  -? 
True. 

Rule  3:  lor  any  b,  an  element  of  1?;  cn,  an  element 

of  CN,  and  p,  an  element  of  K,  b  may 

deliver  a  p  received  oil  cn  if  and  only  if 
rccei''e-packct(cl)(b,  cn),  ccn(b,  cn),  b,  cn, 
p)  ->  True. 

Rule  4;  Tor  any  bl  and  lr2,  elements  of  11,  cnl  and 
cn2,  elements  of  CN;  and  p,  an  element  of 
K;  if  rcccivc-packct(bl,  Cnl,  b2,  cn2,  p)  -> 
lute,  then  unalteicd(p)  ->  True. 

Rule  5:  lot  all  c,  elements  of  1.,  if  scemity- 

rclcvant(c)  ->  True,  then  amiit(c)  ->  21110. 
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I).  The  LAN  Model 

In  modeling  the  scenic  opciatiou  of  the  LAN,  the 
secure  operation  of  the  ItilJ  nnd  the  AC  needs  to  be 
dcsci ibeil.  Inch  will  lie  dcsctilicd  ns  c  collection  of  stale 
machines.  The  states  nnd  the  events  that  ratisc  transitions 
between  them  will  be  deseiibed.  The  communications 
between  these  devices  will  then  be  modeled  to  complete  the 
description  of  the  total  operation  of  the  LAN.  At  that 
point,  there  Should  lie  n  model  fiom  which  the  scemity- 
rclcvant  points  enn  lie  ptosen. 

1.  The  1IIU 

The  fust  device  to  Ik-  deseiibed  is  the  lilt1. 
The  main  function  of  the  lilt)  is  to  send  nnd  icccive 

packets  for  the  Attached  host.  To  do  this,  the  ItlU  must  be 
able  to  establish,  maintain,  and  close  connections.  It  must 
be  nblc  to  distinguish  to  which  connection  a  packet  belongs 
as  well  as  whether  that  picket  is  poimitted  to  l>c  sent  01 
received  The  UK)  must  l>c  able  to  do  this  fot  any  mini  Ik  i 
of  connections,  limited  only  by  its  own  physical  rcsotnccs  of 
those  of  the  attached  host.  It  must  t>c  able  to  communicate 
with  the  AC  thiough  the  IIAC  ami  rrspind  to  NSO 

commands  issued  thiough  the  AC.  finally,  the  lilt  I  must 
realize  when  a  sccuiity-iclcvant  event  has  occuncd  ami 
record  that  event  in  an  audit  log 

The  behavioi  of  a  HIU  is  modeled  by 
describing  the  liTc  of  each  connection,  fiom  binli  until 

death,  that  a  HIU  manages  with  a  separate  state  machine, 
bach  of  these  state  machines,  railed  Connection  State 

Machines  (CSM’s),  models  those  functions  in  the  HIU  that 
establish,  maintain,  and  then  close  a  p.uticuhi  connection. 
Included  in  this  functionality  is  all  of  the  sccutity  checking 
that  is  done  for  that  connection. 

These  CSM’s,  however,  do  not  model  the 

entire  operation  of  the  HIU.  Some  functionalities  not 
modeled  me  the  lllU’s  ability  to  communicate  u'ith.  the 
network  Oi  attached  hosts  and  its  audit  capability.  A 

separate  state  machine,  called  the  HIU  State  Machine  (HSM), 

docs  this  for  each  of  the  CSM’s.  Ihe  HSM  takes  the  input 
to  lire  Hill  and  decides  to  which  connection  it  Ixdongs  and 
then  passes  it  to  (he  CSM  handling  that  connection.  If  a 
CSM  is  not  cuncntly  active  to  handle  the  input,  the  HSM 

initiates  one  that  can. 

The  teal  pm  pise  of  the  HSM  is  to  model 
the  physical  operations  of  the  Hill  When  input  comes  into 
the  HIU,  the  HSM  checks  that  input,  sends  it  to  a  CSM  lot 
a  decision  on  what  action  to  take,  waits  lot  a  icspmsc,  and 
takes  action  appiopriatc  to  that  icspmsc  (sec  ligate  2). 


(1)  wait  -  The  HSM  waits  lot  input 

to  the  HU!  fiom  the  nctwoik,  the  attached  host,  oi  one  of 
the  CSM’s. 

(2)  ekcck-cxlcin.il  input  -  The  lilll 

examines  input  fiom  the  mnwoik  oi  the  host  It  icjects  the 
input  if  it  is  not  addirssed  foi  the  HIU  oi  Ins  been 
damaged  in  some  way.  It  is  heic  that  the  ItlU,  it  operating 
in  inoile  one,  insciLs  seem  it  y  Libels  ion  the  picket  headcis. 

( 3)  |i.ass-io-<  'SM  -  ’I  he  input  is  passed 

to  the  appiopiiatc  CSM.  It  tlicic  is  no  t'SM  available  to 

iiaudic  the  input,  a  state  b  enlcied  that  v.-*II  spawn  one. 

(-1)  spawn  CSM  -  A  new  instantiation 
of  a  CSM  is  Cleared  ‘o  which  the  input  is  pissed. 


(5)  audit  -  Sccutity  iclcvant  events  toe 

logged  in  the  HIU. 

(6)  delivet  -  I'ackcts  ate  dclivcicd  to 

the  attached  host. 

(7)  send  -  backets  ate  transmitted  out 

on  the  bus. 

(8)  change-mode  -  The  0|v  rating 

mode  of  the  1111 1  is  changed. 

('))  rcpnt-failiiic  -  An  attempt  is 

made  to  reput  any  Hill  dele  acd  lailiiic  to  the  AC.  Ibis 

attempt  may  oi  may  not  succeed  dctieading  on  the  lutum  of 
the  failnte. 

(10)  disconnect  -  7  hr  HIU  is 
electrically  disconnected  fiom  the  bus.  This  should  hapten 
aftci  any  failuic  is  detected  ir.gaidlcss  of  whether  or  not  it 
has  been  successfully  tepnted  to  the  AC 

b.  Most  of  the  events  that  cause  HSM 

state  transitions  ate  the  icsult  of  some  output  from  one  of 
the  CSM's.  The  events  me  as  follows. 

(1)  external-input  -  A  pachc'  has 

at  lived  from  the  host  oi  nctwoik 

(?)  new- (ASM  -  The  packet  that  just 
at  lived  t  dilutes  a  new’  CSM  to  handle  it. 

(7)  aiidit-icii  -  A  CSM  has  signaled 
that  some  event  needs  auditing. 


(•1)  audit  full  ■  The  event  jus;  audited 


caused  the  audit  files 
value. 

to  be  la. act 

than 

StMtiC 

thtcshold 

(5) 

dch\cr-ion  * 

A  f 

has 

signaled 

that  a  picket  is  icady  to  lx;  dclivcicii  to  the  host 

(6)  send  ; ci i  •  A  CSM  has  signaled 
that  a  packet  is  ready  to  be  sent  out  on  ,he  nctwoik. 

(7)  change -mode-ieq  -  A  CSM  has 
signaled  that  the  AC  has  iciiuesicd  a  mode  change  for  the 
HIU. 


(8)  disConiHVMct)  A  CSM  has 
signaled  that  the  AC'  has  lerincstcl  .hat  the  HIU  clcetiically 
disconnect  itself  fiom  the  bus. 


(‘))  d«>IK*  -  lh; 

notion  of 

the  cm icnt 

slate  lias  been  successfully  completed. 

(10)  icjvi  - 

The 

packc 

i  that 

at  lived  fiom  the  host  oi  nctwwl. 

intended  I'm  the  Hill. 

was 

dam:u 

*,cd  OI 

not 

i.  H  )  la  dn  ie 

Tf 

!l*  ,1.0  tl' 

■H  \lf 

Hu* 

cm  icnt  stale  lias  not  been  successfully 

com  j  ’K'  1 

vd,  Oi 

the 

HIU  has  detected  some  liniilw.uc  l.iilmc. 

1  Ins 

may  Ii.t| 

i|  VII 

in  any  slate. 

(1?)  teset  -  Die  HIU  lias  jaxt  been 

connected  to  the  nctwoik  and  begun  op-ration. 

(See  l  iguic  3  foi  a  HSM  state  diagram  and  I  igtne  4  foi  a 
HSM  stale  transition  table.) 

c  Tlicic  ate  tlnce  possible  ways  loi  a  HIU 
to  be  iuv.ihcd  in  a  connection.  H  can  Ik  attached  to  a 

host  boat  is  initiating  a  connection,  attached  to  a  host  that  is 
the  recipient  of  a  .onneilion.  oi  attached  to  the  At'.  The 
CSM  manages  individual  connections  and  must.  tWicfoic,  be 
able  to  handle  all  tloee  cases.  As  a  icsult,  the  C  SM  is 
considerably  more  eoinplicavl  than  the  HSM  !  is  states  ate 

as  follows: 

(U  piith  -  This  is  tlic  initial  slate  cl 

the  CSM.  V.T  role  the  HIU  is  to  play  in  the  coimcctiou 
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dcli‘1  mines  I  lie  lie’ll  state  of  llie  CSM. 

(2)  semi  ti|x-n  icq  •  The  bill  just 

received  ;i  ci>iim.el um  civil  icquest  fiom  its  attached  host. 
The  HSM  is  signaled  t.i  fonv.nl  I h is  request  to  liic  AC  foi 

a,. pi  oval. 

(3)  delivci  open-ict)  -  II’C  Hit  l  just 
iiefivi.1  a  connection  0|vu  icqucsi  that  the  AC  has 
approved.  Hie  HSM  is  signaled  to  tic  I  i  vc  t  this  icquest  hi 
llw  .Uiachcd  host. 

(•1)  wait  0|vii  •  I  idiot  t lie  oiiginuting 
Hill  is  w.iituig  hi'  a  meponsc  I  mill  the  AC.  or  the  iccciving 

llll  is  v.utii'i,  foi  .1  icspur-c  fiom  die  attached  ho„l 

(  S)  m’lily-AC  o|Knaeh  -  The  receiving 
Hill  has  jus;  ieo.i\Cd  appiov.il  bom  the  aiiavlicd  host  that 
the  tuniiceli.tr  may  He  ope ncd.  the  ItSM  is  signaled  to 

until  y  the  AC. 

(6)  notify  hosl-o|x'it  nth  -  1  lie 

ot  initiati  n',  nil!  1ms  just  teevived  appunal  limn  the  AC  that 
the  it\|. tested  connect  ion  may  l<e  o|x-nen  The  HSM  is 
signaled  It’  notify  ihe  attached  host 

(7)  intlil  /- AC-n|Vtt  ink  -  I  he 
receiving  hll  has  just  icccivcd  void  lhai  iis  attached  host 
has  tcliisetl  the  purposed  cimiiccliiiii.  I  he  HSM  is  signaled 
to  notify  the  AC. 

v  K)  notify  host  ttix'ii-nah  -  The 

Ot  initiating  Hill  has  just  received  until  that  the  pi.'|\iscd 
connect!  so.  li”  sonic  unknown  reason.  has  Hcen  tcltised 
(lie  ltjM  is  signaled  It'  notify  its  attached  host. 


('>)  wait  set  status  teq  -  A  host  to  host 
■■section  is  about  to  Iv  op'iicd  ot  closed  The  CSM  is 

waiting  for  the  AC  to  in?  It  net  it  to  sc!  ot  tcsel  the 
connection  status  •nfoiniatioii 

(101  set  status  -  The  AC  has 

instinct' d  that  the  connection  sl.,tus  lv  set,  and  this  is 
done. 

(II)  notify  AC-status-set  -  t  he 
■ncctimi  stntus  of  the  CStvt  has  been  successfully  set. 
The  HSM  is  signaled  to  notify  tic.  AC. 

(17)  tinth'  -  Out  of  four  auditable 
events  tins  jist  ocemred  io  the  CSM:  a  picket  has  nt lived 
that  cannot  he  delivered,  a  packet  itas  auived  that  cannot  lie 
sen',  tt  connection  has  been  opened,  or  one  has  been  closed 

All  four  events  must  lie  audited,  and  the  HSM  is  signaled 

to  tin  so 

(17)  wait-input  -  a  connection  is 

presently  in  picp.css.  The  CSM  is  waiting  ftoni  iti'iut  ftotn 
the  nctwoik  ot  the  host. 

(1-1)  check  net  send  -  A  picket  has 

at  rived  at  Ihe  HIU  ftotn  the  attiietteit  host.  The  packet  is 

cheeked  with  ivsivet  to  sccuiity  to  tlctct  iine  if  ii  may  iv 

sent  out  in  this  connection. 

(lit  send  -  A  picket  has  been 

determined  fit  t  >  scud  in  this  connection  The  HSM  is 

signaled  io  send  it  out  on  the  nctwoik. 

(Ifr)  check-host  delivery  -  A  packet 

has  a; lived  at  the  Hill  ftotn  the  nr.t'viih.  In  this  state,  the 

packet  ts  .“heckcd  with  respect  to  sccuiity  In  determine  if  it 
may  be  delivered  in  this  connection.  The  picket  is  also 

checked  to  sec  if  it  is  a  close  connection  icquest. 

(17)  deliver  •  A  packet  lias  Ivcu 

dctctiuiiiod  fit  to  dclivet  in  this  connection.  The  HSM  is 
signaled  to  delis  c  it  to  the  attached  lies!. 

(1R)  notify  host  closed  -  the  HIU  has 

me,'  is  ml  notice,  cither  ftoni  a  host  m  the  AC,  that  the 

current  connection  has  Ivcn  closed  'I  lie  HSM  is  signaled  to 
notify  the  attached  host. 

(19)  notify  AC-elnscd  •  lire  cuiicnt 

connection  has  been  closed  The  AC  is  notified  so  that  the 
Hill  status  may  Ik  reset. 

(20)  notify  host  not-f.nk.ui/cd  the 
host  has  attempted  to  send  unruthoti/'d  nifoiin.dion  out  on 
the  network.  The  HSM  is  siticd  d  to  notify  the  liosi  of 
the  crroi. 

(21)  scml-nudii  -  The  Hill  h.o 

teceived  a  icquest  fiom  the  AC  to  begin  sending  its  bcally- 

stored  audit  data.  Tit.-  HSM  is  signaled  to  mod  ;.  (neket  of 
audit  data 

(7.2)  ss-.tit  nk-to-send  audit  -  The  itlll 

is  ready  to  send  the  AC  suuiil  tki'.a.  1  In  CSM  i.  w.,iling 

foi  coiifitiiiatioii  that  Hie  AC  is  medy  «o  receive  it. 

(7a)  notify  At  audit  lull  -  The  HSM 

has  icali/cd  that  i  t  s  audit  files  ate  trcaily  lull  The  CSM 

signals  ll:c  11SM  to  notify  the  AC 

(24)  notify- At. -audit  lent  The  audit 
files  have  been  complete  !y  sent  to  tnc  AC.  T  he  HSM  is 
signaled  to  no'ify  the  AC, 


(75)  chinod  -  The  Hit)  has  received 
n  icquest  fiom  the  AC  to  cn.uigc  its  operating  muds.  The 
HSM  ;s  signalct!  l->  do  so. 

(?(>)  notify- AC-inode  changed  -  Toe 
updating  mode  of  the  1MU  lias  just  been  changed  Tlir 
ltSM  is  signaled  to  notify  the  AC 


3.’ 


(27)  disconnect  -  A  disconnect  request 
has  arrived  at  the  RIU  from  the  AC.  The  HSM  is  signaled 
to  electrically  disconnect  the  HIU  from  the  network. 

(28)  death  -  The  connection  has  been 

completely  closed  and  the  CSM  is  no  longer  needed.  'Hie 

CSM  is  terminated. 

d.  The  events  that  cause  CSM  state 
transitions  arc  as  follows: 

(1)  host-AC-npen  -  The  HIU  has 

received  a  message  from  its  host  requesting  a  connection  to 
Ire  opened.  This  is  one  of  the  entry  cvcnis  to  the  CSM. 

(2)  AC-host-open  .  The  niU  has 

received  a  packet  from  the  AC  informing  it  that  another 
host  wishes  to  open  a  connection  to  it.  This  is  one  of  the 
entty  events  to  the  CSM. 

(3)  host-AC-open-ack  -  The  RIU  has 

been  notified  that  its  host  has  accepted  the  proposed 

connection. 

(4)  host-AC-open-nnk  -  The  RIU  has 

l>ccn  notified  that  its  host  has  not  accepted  the  proposed 
connection. 

(5)  AC- host-opcn-ack  -  The  HIU  has 

been  notified  that  its  host's  connection  request  has  been 
approved  and  will  be  opened. 

(6)  AC-host  o|ion-nak  -  The  HIU  has 

been  notified  that  its  host's  connection  request  has  not  been 
approved  and  will  not  be  opened. 

(7)  set  stat  req  -  A  perckct  has  umvcd 
at  the  BiU  from  the  AC  requesting  that  the  HlLTs 
connection  status  information  be  changed. 

(8)  front-host  -  While  involved  in  a 

connection,  the  BIU  has  received  a  message  from  its  host 

addressed  to  that  connection. 

(9)  from-nct  -  While  involved  in  a 
connection,  the  IIIIJ  has  received  a  locket  from  the  network 
addressed  to  that  connection. 

(10)  net-authorized  -  Cither  a  racket 

from  the  network  or  a  message  from  the  host  arrived  at  the 

1IU  and  cannot  be  passed  through  it. 

(11)  closed  -  ‘Pircc  things  can  cause 

this  event:  a  host  notifies  its  HIU  that  the  current 

connection  is  over,  a  packet  arrives  at  the  131U  signifying  the 
end  of  the  connection,  or  *hc  closing  of  the  connection  was 
just  audited  by  the  HIU. 

(12)  kill-con-rcq  -  A  packet  from  the 

AC  just  arrived  at  the  HIIJ  instructing  it  to  close  that 
connection. 

(13)  BHJ-AC-slart  -  A  packet  just 

arrived  at  the  B-AC  from  some  other  RIU  requesting  a 

dialogue  with  the  AC,  usually  regarding  the  opening  or 
closing  ol  a  connection.  This  is  one  of  the  entry  events  to 
the  CSM. 

(14)  AC-HIU-start  -  A  message  just 

arrived  at  the  B-AC  from  the  AC  initiating  a  dialogue  with 
some  other  BIU,  usually  regarding  the  opening  or  dosing  or 
a  connection.  This  is  one  of  the  entry  events  to  the  C'SM 


communication  has 

(13) 

ended. 

BIU- AC-end  -  rite 

HlU-'o-AC 

communication  has 

(10) 

ended. 

AC-BIU-end  -  The 

AC-to  BIU 

(17) 

done  -  The  action  in 

the  cut  rent 

State  has  been  successfully  completed. 

(18)  audit-full  -  The  BSM  has 
realized  that  the  audit  files  arc  nearing  capacity  and  is 
requesting  that  they  be  sent  to  the  AC.  This  is  one  of  the 
entry  events  to  the  CSM. 

(19)  audit-icq  -  A  packet  has  artived 
at  the  BIU  from  the  AC  requesting  the  HlLTs  audit 
information  be  sent  to  the  AC.  This  is  one  of  the  enttv 
events  to  the  CSM. 


(20)  more-audit  -  Audit  information 

has  been  sent  from  the  BI'J  to  the  AC,  hut  there  is  still 
more  to  send. 

(21)  eh  moo- req  -  A  packet  has 
artived  at  the  BIU  from  the  AC  requesting  that  BIU  to 
change  its  operating  mode.  This  is  one  of  the  entry  events 
to  the  CSM. 

(22)  disconncct-rcq  -  A  packet  has 

arrived  at  the  BIU  from  the  AC  instructing  it  to  di. connect 
itself  from  the  bus.  T  his  is  one  of  the  entry  events  to  the 
CSM. 

(See  Figure  5  for  a  CSM  state  diagram  and  Figure  6  for  a 
CSM  state  transition  table.) 

NGTE:  There  is  a  significant  deficiency  in  the  CSM  as  it 

has  been  described.  It  has  been  assumed  that  a  connection 
already  exists  when  communications  occur  between  the  B-AC 
and  another  BIU,  but  in  reality,  a  connection  would  actually 
have  to  be  opened  and  then  closed  for  such  a 
communication  to  take  place.  This  is,  however,  reflected  in 

the  definitions  of  conncct-opcn  and  conncct-closc  and  docs 
iioi  cause  any  of  the  total  l.AN  functionality  to  lx:  lost. 


2.  The  Access  Controller 

The  second  device  to  be  described  is  the 
AC.  The  AC  has  the  primary  responsibility  to  ensure  the 
secure  operation  of  the  TAN.  Since  the  BlU’s  turn  to  the 
AC  for  decisions  regarding  the  permissibility  of  Imst-to-host 
connections,  the  AC  must  be  capable  of  making  those 
decisions.  The  AC  must,  therefore,  know  what  is  hnptxtnmg 
on  the  TAN  at  all  times. 

The  AC  maintains  the  MAC,  DAC,  and 
connection  tables  and  is  responsible  for  setting  and  resetting 
the  connection  status  in  tire  HlLTs.  It  handles  the  TAN 
audit  files.  The  AC  is  also  the  machine  through  which  the 
NSO  issues  commands  such  as  instructing  a  HIU  to  change 
operating  modes,  send  audit  data,  break  connections,  and 
actually  disconnect  itself  from  the  Inis. 

The  AC  is  modeled  similar  to  the  HIU. 
There  wiil  be  a  state  machine,  called  the  Access  Controller 

State  Machine  (ACSM),  that  describes  the  actual  operations 
of  the  AC  (Figure  7).  These  generic  operations  (such  as 
sending  ami  receiving  data  from  the  nctm.uk,  auditing,  and 
accessing  tables)  arc  described  independent  of  any  particular 
network  connection  or  NSO  command. 

There  will  also  be  instantiations  of  another 

state  machine,  the  Connection  State  Machine  -  Access 
Controller  (CSM-AC),  to  manage  specific  individual 
communications  with  a  1IIU  or  the  NSO.  These  CSM- AC's 
signal  Ihc  ACSM  when  they  need  some  action  performed. 

a.  lire  states  fur  the  ACSM  tire  as  fullness: 

O)  "ait  -  Ihc  AC  "aits  for  input 

from  the  network,  the  NSO,  or  one  oT  the  CSM-AC’s. 

(2)  pass-to-CSM-AC  -  Input  is 
checked  for  ptoper  format.  The  data  is  then  passed  to  the 
appropiiatc  CSM-AC.  If  there  is  no  CSM-AC  available  to 

handle  the  input,  a  slate  is  enteted  that  will  spawn  one. 
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(3)  spawn-CSM-AO  -  A  new 

instantiation  of  a  CSM-AC  is  created,  and  the  input  is 

passed  to  it 

(4)  audit  -  Security-relevant  events 

occurring  in  the  AC  are  logged  in  audit  Tiles.  This  includes 

entering  audit  data  received  fiom  individual  BIlTs. 

(5)  access-tables  -  Either  the  MAC, 
DAC,  or  connection  tables  arc  read  from  or  written  to. 

(6)  net-output  -  Data  is  sent  to  the 

B-AC  for  transmission 

(7)  NSOoutput  -  The  NSO  is 

notified  of  some  event,  either  the  completion  of  one  of  his 
requests  or  some  problem  with  tiic  LAN. 

(8)  disconnect  -  The  AC  is  no  longer 

in  control  of  the  network.  Either  the  LAN  continues 
operating  as  it  was  when  the  state  was  entered  with  no 

further  opens  or  closes,  or  an  alternate  AC  is  notified  to 
assume  the  AC’s  responsibilities  in  the  case  of  a  redundant 
AC.  In  the  second  ease,  the  assumption  has  been  made 
that  the  two,  or  maybe  more,  AC’s  have  been  kept 
identical. 

b.  The  events  that  cause  ACSM  state 

transitions  arc  as  follows: 

(1)  input  -  A  message  has  just 

arrived  at  the  AC  from  either  the  AC  or  the  NSO. 

(2)  ncw-CSM-AC  -  There  is  no 

CSM-AC  currently  expecting  the  last  received  message; 
ihcrcfote,  a  state  must  be  entered  to  spawn  one. 

(3)  acccss-rci|  -  A  CSM-AC  has 

signaled  a  requirement  to  access  one  of  the  tables  kept  by 

the  AC. 

(4)  audit-rcq  -  A  CSM-AC  has 

signaled  that  some  event  needs  to  be  audited  or  that  a 

Bllfs  audit  information  needs  to  be  saved. 

(5)  audit-full  -  The  last  event  audited 
caused  the  audit  files  to  be  larger  than  some  threshold 
value. 

(6)  net-output-req  -  A  CSM-AC  has 
signaled  that  some  message  needs  to  be  sent  to  a  BIU. 

(7)  NSO-output-icq  -  A  CSM-AC  has 
signaled  that  some  message  needs  to  be  sent  to  the  NSO. 

(8)  done  -  The  action  of  the  current 
sta‘c  has  been  successfully  completed. 

(9)  reject  -  The  input  to  the  ACSM 

was  unreadable. 

(10)  AC-disconncct  -  'Die  AC  ha; 
instructed  the  B-  AC  to  disconnect  itself  from  the  network. 

(11)  failmc  -  A  major  failure  ha; 

occurred  in  tire  AC. 

(12)  reset  -  The  AC  has  just  beer 
activated  ami  is  assuming  control  of  the  LAN. 

(See  Figure  8  for  ar.  ACSM  state  diagram  and  Figure  9  for 
au  ACSM  state  tiansition  table.) 
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FIGURE  9:  ACSM  STATE  TRANSITION  TABLE 


c.  The  suites  for  the  CSM-AC  are  as 

follows: 

(1)  birth  -  This  is  the  initial  state  of 

the  CSM-AC.  What  action  the  AC  takes  on  entry  into  the 

CSM-AC  is  determined  by  the  reason  it  was  spawnd, 

(2)  gct-MAC/DAC-ii  To  -  The  AC 

needs  to  make  a  decision  altout  a  connection  open  request 

and  must  consider  the  pertinent  MAC  and  DAC  information. 
In  this  state,  the  ACSM  is  signaled  to  retrieve  this 

information. 

(3)  check-open  req  -  The  open 

request  just  received  is  checked  against  the  MAC  and  DAC 

information  just  retrieved. 

(4)  fnrward-cpcn  req  -  The  open 

request  has  been  approved  by  the  AC,  and  the  ACSM  in 

signaled  to  forward  the  request  to  the  recipient  host. 

(5)  wnit-open  -  The  AC  is  waiting 

for  a  response  to  the  forwarded  open  request  from  the 

recipient  host. 

(6)  notify-hnst-npen-nak  The  <'|>cn 

request  in  question  has  Irccn  denied  cither  by  the  AC  or  by 
the  recipient  host,  and  the  ACSM  is  signaled  to  notify  the 

requesting  host. 


is  closing.  Therefore,  two  separate  CSM-AC  s  wilt  be 
spawnd.  each  catering  this  state  only  once. 

(8)  wnit-statns-sct  -  After  instructing 
tire  BIU  to  change  its  status  information,  the  CSM-AC  waits 
for  confirmation  that  tire  information  Iras  been  changed. 

(9)  notify-host-opcn-ack  -  The  AC 
and  the  recipient  host  have  approved  a  1  st’s  open  reqncst, 
and  the  status  information  in  the  rccipii  .  host's  BIU  has 
also  been  set  for  the  connection.  The  A'  SM  is  signaled  to 
notify  the  requesting  host  of  tlris  and  to  rpect  its  status  to 
be  set  for  the  connection. 


(10)  update-conncction-tablc  -  A 
connection  has  just  been  opened  or  closed,  and  the  AC  s 
tnhlrw  are  undated  to  reflect  this. 


(II)  audit  -  The  action  performed 
during  a  CSM-AC's  life  must  be  audited  before  its  death. 
The  ACSM  is  signaled  to  record  some  auditable  event  in  the 
AC’s  audit  files. 


(12)  notify-HIU-scnd-atidit  -  A 
condition  has  arisen,  either  a  IIIU  message  or  an  NSO 
request,  that  requires  a  BIU  to  send  its  audit  data  to  the 
AC.  The  ACSM  is  signaled  to  notify  the  IIIU  that  the  AC 
is  ready  to  receive  the  audit  data 

(13)  wait-audit-data  -  Tire  CSM-AC  is 
waiting  for  a  BIU  to  transmit  some  audit  data. 


(14)  storc-audit-data  -  Tire  ACSM  is 
signaled  to  store  a  BILLS  audit  data  in  the  AC’S  audit  files. 


(15)  notify-BIU-changc-modc  -  A 
request  has  come  from  the  NSO  to  change  the  operating 
mode  of  a  BIU.  The  ACSM  is  signaled  to  instruct  the  BIU 
to  change  its  operating  mode. 


(16)  wait-mode  changed  -  The  CSM- 
AC  is  waiting  for  confirmation  that  the  BIU  changed  its 
operating  mode. 


(17)  nolify-HIU-disconncctcd  -  A 
request  Iras  come  from  tire  NSO  to  disconnect  a  BIU  from 
tnc  LAN.  Tire  ACSM  is  signaled  to  instruct  the  BIU  to 
disconnect  itself. 

(18)  notify-NSO-HiU-disconncctod  -  The 
ACSM  is  signaled  to  notify  the  NSO  that  the  BIU  lias  been 
instructed  to  disconnect  itself  from  the  LAN.  There  is  no 
actual  confirmation  from  the  LAN  that  the  disconnect 
actually  happened;  therefore,  the  NSO  should  probably  verify 
the  disconnect  for  himself. 

(19)  notify-NSO- AC-audit-full  -  The 
ACSM  has  noticed  that  die  last  piece  of  audit  data  caused 
the  AC'S  audit  storage  area  to  grow  larger  than  some 
threshold  value.  The  ACSM  is  signaled  to  notify  the  NSO 
of  this  fact. 


(20)  update  DAC-tablc  -  Ti.c  NSO 
has  instructed  the  AC  that  a  host's  DAC  table  is  to  lie 
updated,  and  the  ACSM  is  signaled  to  make  the  changes. 

(21)  updalc-M  AC-table  -  The  NSO 
lias  instructed  tire  AC  that  a  host’s  MAC  table  is  to 
updated,  and  the  ACSM  is  signaled  to  make  the  changes. 

(22)  notify-NSO-tahle  updated  -  The 
ACSM  is  signaled  to  notify  the  NSO  that  the  requested 
changes  have  been  made. 


(7)  scnd-statns-infr)  -  A  connection 
liclwecn  two  hosts  is  alxrut  to  Ire  o|x:iicti  or  closed,  and  die 
llUTs  need  to  l>c  instructed  to  change  their  connection  status 
information.  The  ACSM  is  signaled  to  instruct  each  one  of 
the  BIU’s  to  change  this  information.  This  slate  will  be 
entered  twice  during  a  connection  opening;  the  first  to  set 
tire  recipient  host’s  B1IJ  and  the  second  for  the  requesting 
host's  BIU.  During  a  close,  cacti  BIU  will  notify  tire  AC  it 


(23)  notiry-DIU-comrcction-killcd  -  The 
NSO  lias  instructed  that  a  connection  be  terminated  T  lie 
ACSM  is  signaled  to  notify  one  of  the  URLs  to  Kill  the 
connection  at  its  end.  To  completely  kill  an  active 
connection,  two  separate  CSM-AC's  need  to  lie  spawnd  -  one 
for  each  BIU. 
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(24)  wait-closed  -  The  CSM-AC 
realizes  that  a  connection  was  just  killed  and  is  waiting  fnr  a 
BIU  to  send  the  connection  closed  response  to  the  AC. 

(25)  death  -  The  task  that  the 
CSM-AC  was  spawned  to  perform  has  been  completed  and 
audited,  and  the  life  of  the  CSM-AC  is  terminated. 

d.  The  events  that  cause  CSM-AC  state 
transitions  arc  as  follows; 

(1)  host-AC-0|icn-req  -  A  host  is 

requesting  permission  to  open  a  connection  with  another 
host. 

(2)  hosl-AC-open-ack  -  A  host  has 

just  accepted  a  connection  open  request  that  had  been 

forwarded  by  the  B-AC. 

(3)  host-AC-open-nak  -  A  host  has 

just  refused  a  connection  open  request  that  had  been 

forwarded  by  the  AC. 

(4)  not-authorized  -  A  connection 
open  request  failed  to  pass  the  MAC  and  DA.C  checks. 

(5)  slat-set-#  I  -  The  AC  has  received 

confirmation  that  the  status  information  of  a  BIU  was 

successfully  set.  This  event  occurs  when  the  UIU  in 

Question  was  the  recipient  of  the  open  request 

(6)  stat-srt-#2  -  The  AC  lias  received 

confirmation  tliai  the  status  information  of  a  BIU  was 

successfully  set.  This  event  occurs  when  the  BIU  in 

question  was  the  originator  of  an  open  request  or  is  in  the 

process  of  closing  its  end  of  a  connection. 

(7)  closed  -  A  BIU  has  notified  the 

AC  that  its  end  of  a  connection  has  been  closed.  This 

could  hapiien  as  the  Jesuit  of  a  normal  dose  or  from  the 

request  of  the  NSO. 

(8)  NSO-kill-critnicclion  -  The  NSO 
lias  requested  that  a  BIU  close  its  end  of  a  connection. 


(9) 

BlU-AC-audit-full 

-  A  BIU 

has 

notified 

the  AC 

that 

its  audit  files  are  full 

and  need  to 

be 

sent  to 

the  AC. 

(10) 

NSOarntitrcq  • 

The  NSO 

has 

requested  that  a 

BIU 

send 

its  audit  Fries  to 

the  AC 

(11) 

audit-data 

The  input 

just 

received 

was  BIU 

audit  data. 

(12) 

audit-sent 

The  BIU 

has 

informed  the  AC  that  all  of  its  audit  data  has  been  sent. 

(  13)  NSO-rlisconnect-BlU  -  The  NSO 
has  requested  that  a  BIU  1c  disconnected  from  the  1.AK 

(14)  NSO  update -MAC-tablc  -  The 

NSO  has  requested  that  a  change  be  made  to  a  host's  MAC 
tables. 

(15)  NSO  upt lalc-UAC- table  -  T  he 

NSO  has  requested  that  a  change  be  made  to  a  host's  UAC 
tallies. 

(16)  NSO-ehangcTTIU-iiiodc  -  The 

NSO  has  requested  that  a  lllU’s  o|icrating  mode  be  changed. 

(17)  BlU-niodc-changcd  -  The  AC  lias 
leccivcd  confirmation  that  a  Hill’s  operating  mode  has  been 
changed 

(18)  AC-audit-full  -  The  ACSM  ha 
just  signaled  that  the  AC's  audit  data  storage  area  is  ncaiing 
capacity  and  that  the  NSO  needs  to  lie  notified. 

(19)  done  -  The  action  ill  the  current 
state  has  been  successfully  completed. 


(See  Figure  10  for  a  CSM-AC  state  diagram  and  Figure  11 
for  a  CSM-  AC  state  transition  table.) 
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NOTH:  The  same  deficiency  exists  in  the  description  of  tire 
CSM-AC  as  that  in  the  CSM.  Tire  CSM-AC  docs  not 
account  for  the  opening  of  connections  with  lilLTs  with 
which  it  communicates. 

3.  The  Hus 

The  bus  is  the  last  part  of  the  LAN  that 
needs  to  be  modeled.  Tiic  bus  is  the  cable  that  connects 
all  of  the  nnj’s  on  the  LAN.  When  a  l)IU  wishes  to 
transmit  a  packet,  it  broadcasts  it  on  the  bus.  If  all  goes 
well,  it  arrives  at  every  BIIJ  on  the  bus,  including  the 
sender.  Tire  destination  BIU  accepts  the  packet,  and  the 

rest  ignore  it.  The  bus  never  guarantees  that  the  packet 
sent  is  the  one  received.  That  is  the  HlU's  problem. 

The  bus  is  modeled  with  the  assumption 

that  there  is  a  buffer  at  each  interface  to  the  bus.  When  a 
fllU  wishes  to  send  a  packet,  it  writes  that  packet  into  the 
buffer  at  its  bus  interface.  The  property  of  the  bus  is  to 
copy  the  contents,  not  necessarily  correctly,  to  every  other 
buffer.  When  something  is  written  into  one  of  those 
buffers,  the  Dill  at  that  interface  treats  that  as  a  received 

packet.  It  is  up  to  that  1MU  to  determine  if  that  packet  is 

correct  or  even  addressed  to  it  (see  Figure  12). 


r-icimr  12  riiK  bus 


IV.  SUMMARY 

This  paticr  is  a  first  attempt  at  specifying  and  then 
modeling  a  security  policy  for  an  MLS  LAN.  It  describes  a 
policy  that  gives  the  reader  an  intuitive  feeling  of  what  it 

means  for  a  LAN  to  operate  securely  by  putting  forth  a  list 

of  mles  that  must  lie  obeyed  along  with  motivation  for  each 

rule.  It  then  tries  to  formalize  these  rules.  Finally,  a 

fairly  lengthy  description  of  the  LAN  was  presented  by 
describing  each  device  on  the  LAN  with  intercommunicating 
state  machines. 

Since  this  a  fust  attempt  at  the  model,  there  me 
naturally  some  aspects  of  the  LAN  that  have  not  Ixcn  fully 
specified  in  the  model.  Also  nn  formal  proofs  have  been 
attempted  What  is  hoped,  however,  is  that  there  is  now  a 
foundation  which  will  evolve  inlo  a  fully-specified  MLS  LAN 
model  that  is  provably  secure. 
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ABSTRACT 

TC32/TG9  is  a  recently  formed  Task 
Group  within  the  European  Computer 
Manufacturers  Association  standards 
body  (ECMA) .  It  has  been  tasked 
with  defining  an  application-layer 
framework  for  Security  in  open 
Systems,  a  framework  which  will 
ultimately  lead  to  the  definition 
of  standard  security  support 
applications  that  communicate  in 
the  OSI  environment  using  standard 
application-layer  protocols. 

This  paper  reports  on  some  of  the 
early  work  of  TG9  completed  mainly 
during  1986.  It  describes  an 
informal  secure  systems  model  or 
framework,  in  which  security  is 
supported  by  a  number  of  discrete 
security  "facilities".  Tue  paper 
then  goes  on  to  report  on  some  of 
the  detailed  work  that  has  been 
started  on  analyzing  requirements 
for  the  passing  of  security  data 
around  a  distributed  system.  It 
addresses  the  topic  of  access 
authorization  and  offers  a  uniform 
approach  which  caters  for  a 
spectrum  of  access  control  schemes 
ranging  from  capability  systems  to 
access  control  lists. 
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1.  INTRODUCTION 

TG9  is  a  Task  Group  of  Technical 
Committee  32  (TC32)  of  the  European 
Computer  Manufacturers  Association 
(ECMA) .  Its  responsibility  is  to 
deve] op  a  framework  for  the 
provision  of  logical  security  in  an 
Open  Systems  environment  and  to 
develop  standards  for  security- 
related  services  and  protocols,  or 
protocol  elements,  as  required  for 
this  environment. 

The  work  of  the  TG9  group  addresses 
the  ISO  application-layer  view  of  a 
distributed  system.  It  is  aimed  at 
developing  standard  security 
applications  and  standard 
communications  protocols  both 
between  the  applications  themselves 
and  between  them  and  the  productive 
applications  with  which  they  share 
the  system.  In  some  cases  it  is 
envisaged  that  standard  protocol, 
elements  will  be  developed  with 
which  existing  application-layer 
protocols  can  be  extended. 

The  world  of  the  TG9  framework  is 
one  of  end  users  in  control  of 
entities  that  communicate  via 
Application  Service  elements  (Ref 
1) .  The  generic  term  application 
is  used  in  the  text  that  follows, 
to  denote  one  of  these  entities;  so 
in  TG9  terms  a  file  service,  an 
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office  mailbox,  a  print  spooler,  or 
a  UNIX  operating  system  offering 
general  purpose  computing 
facilities  to  its  users  are  all 
examples  of  applications „ 

The  TG9  group  is  primarily 
concerned  with  the  ways  in  which 
applications  interwork  rather  than 
how  they  are  constructed 
internally.  TG9  therefore 
concentrates  its  efforts  on 
network-wide  aspects  of  security, 
only  looking  inside  applications  in 
order  to  establish  what  externally 
communicated  security  data  they  may 
need  (or  at  least  benefit  from)  in 
order  to  do  their  own  job.  This 
split  between  views  of  security 
external  to  and  internal  to 
applications  is  fundamental  to  the 
approach  and  is  further  discussed 
in  Section  2. 

In  either  view,  security  is 
obtainable  only  via  the 
implementation  of  a  variety  or 
control  and  monitoring  functions, 
the  requirements  for  which  are 
determined  according  to  whatever 
security  policy  is  defined  for  the 
view.  TG9 ' s  secure  systems 
framework  identifies  a  general  set 
of  these  functions  and  divides  them 
into  elements,  each  one  having  a 
single  coherent  role  to  play  in  the 
provision  of  the  total  security 
picture . 

These  elements  are  referred  to  as 
Security  Facilities  and  they  are 
described  in  Section  3.  The 
framework  must  also  show  how  these 
elements  interact  with  each  other 
and  consequently  which  combinations 
of  elements  are  appropriate  to  form 
standard  security  support 
applications;  this  is  a  major  area 
of  current  activity  for  TG9 .  A 
walkthrough  of  interactions  that 
could  occur  when  a  user  logs  on  to 
a  system  and  attempts  access  to  an 
application  is  given  in  Section  4. 
The  walkthrough  should  be  taken  as 


illustrative  rather  than 
definitive;  it  leads  naturally  into 
the  second  part  of  this  paper 
(Section  5)  which  covers  one  major 
aspect  of  the  detailed  work  being 
done  within  TG9 .  The  topic  is  that 
of  access  authorization. 

Whereas  authentication  relates  to 
the  process  of  proving  claims  of 
identity,  authorization  relates  to 
the  process  of  controlling  access 
by  already  identified  subjects  to 
already  identified  protected 
objects*.  The  paper  aims  to  show 
that  existing  ad  hoc  authorization 
methodologies  can  be  fitted  into  a 
unifying  framework  in  which 
apparently  quite  different 
techniques  appear  as  different 
parts  of  a  continuously  varying 
spectrum.  Ir.  particular  the  two 
authorization  approaches 
characterized  by  capabilities  and 
access  control  lists  are  shown  to 
be  extremes  of  this  spectrum,  each 
of  which  has  its  advantages  and 
disadvantages.  See  also  References 
3  and  6. 

♦Following  normal  security 
conventions,  active  entities 
requesting  access  to  other, 
protected  entities  in  the  system 
are  referred  to  in  this  paper  as 
subjects  and  the  protected  entities 
as  objects. 

2 .  THE  SECURE  SYSTEMS  MODEL 
2 . I  Overview 

In  terms  of  the  open  systems 
Interconnection  (OSI)  model,  the 
level  of  view  addressed  here  is 
application  layer.  The  security 
entities  described  communicate 
using  OSI  services  of  sufficient 
security  to  satisfy  their  needs 
(Ref.  2).  These  needs  take  the 
form  of  guarantees,  to  some 
acceptable  love] ,  that 
communications  between  them  and 
with  their  peers  are  confidential 
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and  unmodified,  and  that  each 
communication  is  with  a  known  and 
identified  peer  entity. 

Section  2.1.1  introduces  the  two 
level  view  of  security  necessary  to 
distinguish  properly  between  the 
network-wide  security  pc1 ' cy  for  a 
distributed  system  and  tne 
individual  security  policies 
support  by  the  applications 
residing  in  the  nodes  of  the 
network.  Section  2.1.2  shows  how 
the  concept  of  a  "subject"  can 
change  according  to  the  nature  of 
the  accesses  that  are  taking  place. 

2.1.1  Internal  and  External 
Application  Views 

There  are  two  fundamentally 
different  levels  at  which  the 
security  requirements  of  a 
distributed  application  network  can 
be  addressed: 

-  at  the  application  access 
level,  concerned  with 
access  to  protected  network 
objects  like  productive  and 
supportive  applications; 

-  at  the  application- 
specific  level,  concerned 
with  access  to  objects 
supported  by  network 
applications,  ] ike  files 
or  documents . 

These  two  levr  of  view  have  quite 
different  requirements,  reflected 
in  different  security  policies 
tailored  to  the  different  kinds  of 
protected  objects  involved  and  the 
different  components  of  the  network 
that  are  responsible  for  their 
support.  Indeed  entities  that  are 
considered  protected  objects  at  one 
level  can  become  accessing  subjects 
at  another.  This  is  illustrated  in 
figure  1. 


Figure  1  Network  and  Application 
Security  Policies 

Figure  1  shows  a  number  of  end- 
users  wishing  to  access  a  number  of 
network  applications,  policed  by  an 
Application  Access  Security  Policy 
(AASP  in  the  Figure) .  One  of  the 
applications  is  shown  with  its 
internal  details  revealed;  it  is 
supporting  a  number  of  protected 
Application-specific  Objects  (AS01 
to  AS03  in  the  Figure)  being 
accessed  both  by  end-users  directly 
and  by  other  applications  in  their 
own  right,  (viz:  user  3  and 
Application  2)  both  being 
constrained  by  the  same 
Application-Specific  Security 
Policy  (AASP  in  the  Figure) . 

It  is  the  support  of  the  AASP  that 
is  the  prime  concern  of  TG9 ,  since 
it  is  in  this  area  that  the 
distributed  nature  of  a  system  is 
most  apparent,  and  standard 
protocols  are  required  to 
communicate  security  related 
information  (e.g.  the  subject 
identity  and  access  privileges 
discussed  in  Section  5)  between 
applici  ions  running  on  end  systems 
of  different  kinds  and  origins. 

2.1,2  Indirect  Access  and 
Proxy 

In  pome  cases  an  application  may  be 
accessed  by  another  application 
(for  example  Application  2  in 
Figure  1)  rather  than  directly  by  a 
user.  There  are  two  possible 
extremes: 

-  the  initiating  application  is 
acting  on  its  own  behalf; 

-  the  application  is  acting 

on  behalf  of  another  subject 
(e.g.  a  human  user). 
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The  first  situation  may  be  used  for 
example  to  restrict  access  to 
objects  held  on  one  application 
(say  a  File  Service  application)  to 
requests  coming  via  another  (say  a 
Database  Service  application) .  It 
is  entirely  appropriate  for  the 
Database  Service  to  act  with 
respect  to  the  File  Service  as  a 
subject  with  its  own  identity  and 
access  privileges.  In  this  way 
end-user  access  to  a  protected 
object  (in  this  case  the  database 
files)  can  be  controlled  in  terms 
of  the  route  and  method  used  to 
access  it.  This  kind  of  control  is 
important  to  commercial 
organizations  (Ref  9) . 

The  second  situation  might  occur 
for  example  when  a  user  wishes  to 
transfer  a  file  directly  from  one 
application  to  another.  The  user 
requests  one  of  the  applications  to 
initiate  the  transfer  on  his  or  her 
behalf.  This  application  is  acting 
as  the  user's  proxy  and  must 
convince  the  other  application  that 
it  is  legitimately  so  doing  before 
the  transfer  will  succeed. 

Hybrid  cases  can  also  exist  in 
which  the  initiating  application 
uses  its  own  privileges  in 
combination  with  those  given  to  it 
by  the  calling  user. 

References  6  and  7  discuss  proxy  in 
more,  detail.  Reference  7  examines 
the  protocols  involved  in  such 
situations . 

3 .  SECURITY  FACILITIES 

At  this  stage  no  assumptions  should 
be  made  about  the  degree  of 
distribution  of  the  facilities; 
this  might  vary  from  being  a  single 
central  network  application  to 
being  an  aspect  of  every 
distributed  supportive  or 
productive  application.  Neither  is 
it  suggested  that  all  of  these 
facilities  need  be  available  on 


every  secure  network.  They  should 
be  viewed  as  a  shopping  list  of 
items  from  which  a  choice  can  be 
made  appropriate  to  the  security 
policy  and  level  of  security 
quality  required  for  the  network. 
However,  by  identifying  the  full 
list,  the  framework  causes 
omissions  to  be  made  evident  and 
any  resulting  security  weaknesses 
intentional  rather  than  accidental . 

The  following  security  facilities 
have  been  identified: 

3 . 1  User  Sponsor 

When  a  human  user  logs  on  to  a 
distributed  computer  system  using  a 
(possibly  remote)  authentication 
facility  (see  3.2)  there  is  a 
requirement  for  local  functionality 
that  sponsors  that  user  to  the 
system,  which  controls  the  user's 
access  to  local  applications  and 
which  monitors  subsequent  activity. 
The  User  Sponsor  is  the  entity  that 
provides  these  services. 

There  are  two  major  security 
responsibilities  that  fall  outside 
the  ambit  of  particular  productive 
applications.  Firstly  the  User 
Sponsor  is  responsible  for  the 
monitoring  of  a  user's  access  to 
local  applications  and  which 
monitors  subsequent  activity.  The 
User  Sponsor  is  the  entity  that 
provides  these  services. 

There  are  two  major  security 
responsibilities  that  fall  outside 
the  ambit  of  particular  productive 
applications.  Firstly  the  User 
Sponsor  is  responsible  for  the 
monitoring  of  a  user's  continued 
presence:  no  single  application  is 

in  a  position  to  time-out  a  user 
after  a  period  of  prolonged 
inactivity  since  the  user  may  well 
have  been  fully  active  in  other 
areas . 

Secondly,  the  U'-er  Sponsor  also 
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serves  the  uaer:  it  organizes  the 
user's  relationships  with  the 
various  security  facilities  that 
come  into  play  before,  between  and 
after  his  direct  use  of  individual 
productive  network  applications. 
There  is  one  instance  of  a  User 
Sponsor  for  each  active  end-user. 

User  sponsors  are  further  discussed 
in  Reference  8. 


3  -  2  Authentication 

The  Authentication  Facility  accepts 
and  checks  subject  credentials, 
communicating  its  conclusions  to 
other  interested  security 
facilities.  The  subject  involved 
will  either  be  an  end-usar  via  his 
or  her  user  sponsor,  a  non-security 
application  acting  as  a  subject,  or 
a  non-security  application  coining 
on-line  and  making  itself  available 
as  an  accessible  network  object. 

Notice  that  the  authentication 
result  if  a  proof  of  identity  at  an 
instant  in  time.  Assurance  of  the 
continued  validity  of  the  mapping 
of  this  identity  must  be  provided 
either  by  other  means  (e.g.  time 
out  by  the  User  Sponsor) ,  or  by 
continued  reauthentication  in  each 
subsequent  data  transfer. 

3 . 3  Association  Management 

When  a  subject  accesses  an  object 
a  data  exchange  takes  place.  To 
provide  the  means  by  which  this  can 
happen,  an  association  is 
established  between  them,  and  this 
must  be  established  and  maintained 
in  a  secure  way.  There  are  three 
aspects  to  this: 

-  Association  management  is 
responsible  for  ensuring 
that,  the  underlying 
communications  are  as 
secure  as  is  required  by 
the  communicating 


entities,  including  assurance,  of 
their  identities. 

-  The  subject  must  have  been 
authorized  to  communicate 
with  the  object.  Association 
management  must  be  sure  either  by 
the  context  within  which  the 
request  was  made,  cr  by 
explicitly  involving  appropriate 
authorization  facilities  (see 
3.6),  that  this  is  the  case. 

-  Any  security  weaknesses 
inherent  in  the  communications 
route  chosen  must  be  reflected  in 
the  access  privileges  of  the 
subject.  For  example  links  on 
which  there  is  no  cryptographic 
protection  should  not  be  used  for 
highly  confidential  data  traffic, 
even  though  the  accessing  subject 
may  be  cleared  to  access  such 
data. 

3 . 4  Security  State 

The  security  state  of  a  distributed 
system  represents  the  current 
condition  of  the  subjects  and 
objects  in  it. 

If  a  user  is  successfully 
authenticated  then  his  or  her 
condition,  as  recorded  in  the 
security  state,  changes;  the  same 
happens  when  a  current  file  access 
is  authorized  or  revoked  or  when  a 
user  logs  off.  The  security  State 
Facility  (SSF)  is  a  passive 
facility  that  serves  to  hold  a 
record  of  the  current  security 
state . 

The  SSF  should  not  be  confused  with 
audit  trail  collection:  SSF  keeps 
the  current  state,  not  a  record  of 
state  changes;  however  changes  of 
security  state  will  often  be  also 
recorded  in  an  audit  trail  using  an 
Audit  Facility  (see  3.8). 
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Tiie  SSF  is  an  abstraction 
representing  the  state  information 
of  all  of  the  elemental  security 
facilities.  It  is  therefore 
clearly  likely  to  be  highly 
distributed,  with  components  in 
every  node  of  the  distributed 
system. 

3 . 5  Security  Attributes 

The  Security  Attribute  Facility 
provides  appropriate  subject- 
related  access  privilege  data  (such 
as  a  user's  security  clearances  and 
group  memberships)  for  already 
authenticated  subjects,  an  object 
related  access  control  data  (such 
as 

its  classification  and  access- 
control-list  entries)  for  protected 
objects.  A  close  relationship 
between  the  authentication  facil ity 
and  the  security  attribute  facility 
is  envisaged,  particularly  with 
respect  to  subject  related 
privilege  attributes.  The  data 
structures  needed  for  both 
facilities  are  very  similar,  both 
being  related  to  the  structures 
defined  by  CCITT  and  ISO  for 
Directories  (Ref  10) .  TG9  has 
provided  input  to  this  work  in 
connection  with  its  proposals  for 
security  controls  (Ref  11). 

3.6  Authorization 

The  Authorization  Facility  uses 
accesr  context,  subject  access 
privilege  attributes  and  object 
access  control  attributes  to 
authorize  or  deny  requested 
accesses  by  subject  to  objects. 

The  concept  of  authorization  using 
privilege  and  control  attributes  is 
further  discussed  in  Section  5. 

3.7  Inter-Domain 

If  a  security  domain  is  defined  as 
that  part  of  a  distributed  system 
to  which  a  single  security  policy 
applies  under  the  responsibility  of 


a  single  security  management 
entity,  then  special  requirements 
arise  when  communication  takes 
place  between  two  security  domains. 
In  particular  if  a  subject  in  one 
domain  wishes  to  access  a  protected 
object  in  a  second  domain, 
additional  rules  are  required  which 
reflect  the  complex  and  varied 
trusted  relationships  that  may 
exist  between  the  different 
security  domains.  Domain  A  may  or 
nay  not  trust  Domain  B  to 
authenticate  its  subjects,  or  may 
do  so  only  to  a  limited  degree. 

Some  objects  protected  by  Domain  A 
may  be  so  sensitive  that  no  extra- 
domain  access  is  permitted  under 
any  circumstances  (Ref  4) .  Also 
Domain  A's  view  of  the  meanings  of 
particular  security  attributes  may 
differ  from  that  of  Domain  B,  and 
finally,  there  may  be  a  need  to 
change  cryptolographic  keys  at  the 
border  between  the  domains.  All  of 
these  matters  require  tile  support 
of  an  Inter-domain  facility. 


This  facility  provides  security 
administrators  with  a  record  of  the 
use  of  the  security  facilities  of 
the  system.  It  is  the 
responsibility  of  other  active 
security  facilities  to  transmit 
audit  information  to  the  Security 
Audit  Facility  according  to  the 
audit  policy  for  the  system. 

3 . 9  Recovery 

This  facility  is  available  to  a 
system  administrator  to  take 
immediate  corrective  actions. 

These  actions  may  come  from  a 
specific  demand  from  the  system 
administrator  himself,  or  may  be 
the  result  of  events  coming  from 
the  audit  facility  (alarms  or 
security  violations)  or  from  other 
security  facilities. 
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3.10 


£ypt<>9 raphic  Support 

Provides  application  layer 
cryptographic  functions  used  both 
by  other  security  support 
facilities  and  by  productive 
applications  to  secure  data  in 
storage  and  transit  in  the 
following  specific  ways  (see  Ref 
2)  : 

-  communications  confiden¬ 
tiality 

-  communications  integrity 

-  data  origin  authentication 

-  non-repudiation  of  origin 

-  non-repudiation  of  receipt 

4 .  walkthrough 

The  following  gives  an  example 
walkthrough  of  a  user  approaching 
the  system  and  accessing  an  object 
controlled  and  supported  by  a 
productive  application.  The 
walkthrough  is  provided  for 
illustrative  rather  than  definitive 
purposes  and  not.  all  the  facilities 
are  involved. 

At  the  beginning  of  this 
walkthrough  it  is  assumed  that  the 
system's  security  facilities  are  up 
and  running  with  secure  1  inks 
established  between  them.  The 
productive  application  of  the 
example  is  already  in  service  and 
authenticated  as  an  accessible 
application  object.  The  terminal's 
User  sponsor  is  also  authenticated 
as  legitimate  (but  no  user  is  yet 
present) .  This  implies  that 
identities  and  addresses  of  these 
entities  are  now  known  to  the 
security  State  Facility. 

A  human  user  sees  that  there  is  a 
computer  system  in  front  of  him  or 
her.  No  other  information  is 
available  (in  this  example).  Tho 
user  depresses  a  terminal  key,  puts 
in  a  magnetic  badge  or  otherwise 
stimulates  the  system. 


1.  The  User  Sponsor  is  activated 
which  connects  the  user  to  an 
Authentication  Facility  and 
mediates  the  authentication 
dialogue  between  them.  The  choice 
of  Authentication  Facility  may  or 
may  not  be  made  by  the  user.  The 
user  authenticates  himself  or 
herself  and  the  Authentication 
Facility  notifies  this  to  the 
Security  Audit  Facility. 

Similar  notification  actions 
occur  also  at  other  points  in  this 
walkthrough  but  are,  from  here  on, 
omitted  for  reasons  of  clarity. 

2.  The  Authentication  Facility 
informs  the  Security  state  Facility 
of  the  successful  Log-on,  naming 
the  User  Sponsor  involved.  The 
Sponsor's  identity  I”  sufficient 
information  to  locate  it. 

3.  The  Authentication  Facility 
asks  the  Attribute  Facility  for  the 
authenticated  user's  access 
privilege  attributes  (possibly 
tempered  by  the  authentication 
method  used)  and  passes  them  to  the 
Security  State  Facility  to  be 
remembered. 

4.  The  user  selects  the  required 
application. 

5.  The  Association  Management 
Facility  is  prompted  by  the  User 
Sponsor  to  set  up  an  association 
between  the  local  and  remote 
application  entit  es  on  behalf  of 
the  user. 

6.  To  do  this.  Association 
Management  refers  tc  the  Security 
State  and  the  Attribute  Facility  to 
obtain  privilege  and  control 
attributes  relating  to  the  user, 
the  service  and  the  quality  of 
association . 

7.  Association  Management  calls 
an  Authorization  Facility  to  check 
the  user's  right,  to  access  the 


remote  service.  Association 
Management  then  sets  up  the 
association  with  the  required 
quality  of  underlying  security. 

ft.  Having  set  up  the 
association,  appropriate  changes 
are  made  by  Association  Management 
to  the  Security  State.  These 
changes  may  include  further 
tempering  of  the  user's  privilege 
attributes  based  on  the  security 
quality  of  the  association. 

9.  The  User  Sponsor  informs  the 
user  that  the  connection  to  the 
application  has  been  made. 

10.  The  user  uses  the  newly 
established  association  to  transmit 
a  first  request  to  the  application 
to  access  an  object  supported  by 
it. 


11.  An  Authorization  Facility  in 
the  productive  application  refers 
to  Security  State,  specifying  the 
association,  so  as  to  obtain  both 
identity  and  access  privilege 
attributes. 

1?.  It  then  obtains  the  access 
control  attributes  associated  with 
the  object  in  question  using  an 
Attribute  Facility  within  the 
application  and  uses  them,  in 
conjunction  with  the  accessing 
user's  privilege  attributes  to 
check  the  legitimacy  of  the  access. 
The  access  is  shown  to  be 
legitimate. 

13.  The  user  accesses  the  object! 


Figure  2  shows  the  conversations, 
between  the  security  facilities 
numbered  using  the  numbering  of  the 
walkthrough  description.  The 
arrows  point  from  initiator  to 
responder  in  each  case.  All 
facilities  may  converse  with  an 


Audit  Facility  or  Recovery 
Facility. 
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5  •  UULMUliOIilZATTON  MODEL 


5,1 


In  tho  real  world,  authorization 
rulings  arc  made  in  the  context  01 
characteristics  possessed  by  the 
parties  involved,  the  state  ol  the 
world  at.  tho  time,  and  the  kind  of 
access  requested. 


In  the  computer  world  wa  use 
similar  concepts.  The 
characteristics  of  the  parties 
involved  are  represented  by  data 
which  can  be  categorized  as 
fol lows ; 


5.1.1  Authorization  attributes 
associated  with  the  subject 
(privilege, attributes) 

For  example  the  subject's  name(s), 
its  role  in  the  system  and  its 
trustworthiness.  Indeed  any 
attribute  is  a  candidate  lor  this 
category,  provided  that  it  is 
associated  with  the  subject?  in 
particular  a  name  of  an  accessible 
object  can  be  an  attribute 
associated  with  a  subject. 


5.1.2  Authorization  attributes 
associated  with  the  object  f control 
atliibilt.es) 

For  example  the  object's  naiad (3), 
its  role  in  the  system  and  its 
degree  of  sensitivity  or  required 
integrity.  Once  again  any 
attribute  is  a  candidate  for  this 
category,  provided  that  it  is 
associated  with  the  object.  In 
particular  a  name  of  an  accessing 
subject  can  be  an  attribute 
associated  with  an  object. 

5.1.3  The  context  within  which  the 
request  is  being  made 


For  example  the  time  of  day,  the 
communications  route  involved,  or 


the  accesses  currently  be 
to  other  objects  by  this  , 
subjects. 


made 

other 


Access  contexts  are  not  further 
considered  in  this  paper,  but  are 
unaer  study  within  the  TG9  group. 


5.1.4  The  kind  of 
requested 


lor  example?  read, 
knov-about . 


access  being 
modify,  use, 


The  rules  of  tho  authorization 
policy  arc  applied  to  values  from 
those  four  categories  and  the 
result  is  essentially  either 
"access  permitted"  or  "access 
denied".  The  algorithm 
representing  the  rules  is  typically 
complex,  involving  complex 
combinations  of  multiple  elements 
fiom  each  category.  One  of  the 
tasks  of  the  standard! zrtion 
process  is  to  bring  some  structure 
to  this  ccv.upl exity  in  a  way  that 
preserves  as  far  as  possible  its 
qener«.tl  applicability. 

Notice  that  authorization 
attributes  can  be  long  lived  or 
short  lived.  For  example 
clearances  and  classifications  tend 
to  be  static  in  nature,  and 
therefore  long  lived.  A  capability 
on  the  otner  hand  may  be  granted  to 
a  subject  for  the  duration  of  a 
session,  part  of  a  session  or  lor  a 
single  access. 

Typically,  authorization  attributes 
are  held  as  tuples,  of  which  one 
part  is  the  attribute's  value  and 
the  other  is  one  or  more  access 
types  associated  with  that  value. 
For  example,  if  an  object  has 
associated  with  it  an  attribute 
containing  the  name  of  a  particular 
subject,  paired  with  an  access-type 
value  of  "read",  there  is  an 
obvious  authorization  rule  that 
could  be  chosen  to  apply,  under 
which  presence  ot  the  attribute 
grants  the  subject  read  access  to 

the  object..  Such  an  attribute 
would  look  remarkably  like  an 
access  control  list  entry. 

Not  all  attributes  require  this 
treatment  however;  for  example  a 
subject  may  have  an  attribute  which 
defines  its  security  clearance. 

Such  an  attribute  will  under  many 
policies  automatically  be 
associated  with  read  access  since 
this  is  fundamental  to  the  concept 
of  security  clearance.  Such  an 
association  could  therefore  be  made 
implicit. 


5-2  HI ustrative  examples 

5.2.1  I f  we  imagine  an  object- 
name/  access  -type  tuple  as  a 
privilege  attribute  (i.e. 
associated  with  a  subject) ,  with 
object-names  also  being  associated 
with  objects  as  control  attributes, 
and  couple  these  with  an 
appropriate  and  obvious 
authorization  rule  we  obtain  what 
is  essentially  a  capability. 


If. 


5.2.2  If  we  imagine  a  "clearance" 
privilege  attribute  and  a 
"classification''  control  attribute, 
and  couple  these  with  an 
appropriate  authorization  rule  we 
have  a  label-based  scheme  which  is 
appropriate  for  supporting  a  real 
world  National  Security  Policy, 

5.2.3  If  we  imagine  subject  name 
as  a  privilege  attribute  and  a 
subject-name/access-type  tuple  as  a 
control-attribute  and  couple  this 
with  an  appropriate  authorization 
rule  we  obtain  what  is  essentially 
access  via  an  Access  Control  List 
entry . 

5.2.4  It  is  easy  to  devise  more 
sophisticated  variants  of  example 

5.2.1  in  which  the  object-name 
becomes  an  object  type  with  more 
than  one  object  possessing  a  given 

•type'  attribute,  giving  the 
capability  a  wider  applicability. 

It  is  a  small  step  further  to 
consider  this  'type'  attribute  as 
becoming  a  security  label,  and  so 
arrive  at  example  5-2.2.  A  similar 
bridge  could  clearly  be  made 
between  5.2.2  and  5.2.3. 

Thus  clearances  are  revealed  as 
generalizations  of  capabilities  and 
Classifications  as  generalizations 
of  access  control  list  entries. 

Figure  3  illustrates  this  gradual 
merging  of  one  concept  into 
another.  It  includes  also  a  bridge 
between  5.2.2  and  5.2.3. 
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f, . 3  Observations  on  the 
examples 

5.3.1  The  ease  with  which  a 
capability  mechanism  can  be 
transmuted  into  a 

clearance/classification  mechanism 
and  th>n  into  a  conventional  access 
contrc  list  mechanism  argues  for 
the  u.  ilness  and  appropriateness 
of  the  underlying  attribute 
framework. 


5.3.2  When  subject  names  are  held 
at  objects  for  use  as  control 
attributes  (e.g.  in  ACL  entries), 
day  to  day  maintenance  of  the 
authorization  policy  is  made 
difficult  for  systems  with  a 
volatile  population  of  subjects. 
Conversely,  when  object  names  are 
held  as  privilege  attributes 
associated  with  subjects  (e.g.  as 
Capabilities)  maintenance  is 
difficult  for  systems  with  volatile 
object  populations. 

Maintenance  is  therefore  clearly  a 
factor  which  should  influence 
choice  of  expression  of  policy,  and 
to  define  a  standard  for  all 
systems  based  on  one  or  other 
approach  is  consequently 
inappropriate. 

Furthermore,  a  practical  system  is 
likely  to  require  an  authorization 
policy  which  uses  multiple 
positions  on  the  attribute 
spectrum.  Figure  4  illustrates  the 
point 
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Typically-  high  security  systems 
might  use  an  ACL  approach  for  their 
discretionary  authorization  poxicy 
and  a  clearance/classification- 
attribute  approach  for  the 
mandatory  policy.  A  subject 
passing  these  tests  can  then  (for 
performance  reasons)  be  given  a 
temporary  capability  which 
subsequently  independently  grants 
the  requested  access. 

5.3.3  In  a  large  distributed 
system,  responsibility  for  control 
of  an  authorization  policy  might  be 
devolved  to  a  number  of  different 
centers.  In  particular,  it  will 
often  be  the  case  that  control  over 
the  introduction  of  users  to  the 
network  will  be  exercised  by  a 
different  authority  from  those  that 
administer  the  individual  services 
on  the  network.  The  former  could 
be  considered  to  be  the  subject 
administrator  of  the  network,  and 
the  latter  the  object 
administrators.  On  system  with 
multiple  cooperation  authentication 
services  there  may  be  more  that,  one 
subject  administration  authority. 
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It  is  useful  to  examine  the 
authorization  attributes  that  each 
authority  controls.  In  general  it 
seems  obvious  that  subject 
administrators  should  be 
responsible  for  privilege 
attributes,  with  temporary 
attributes  of  either  kind  being 
allocated  by  object  access  control 
logic  as  implementation  expedients. 
This  fits  in  reasonably  well  with 
the  real  world  perceptions  of  these 
attributes.  It  is  entirely 
appropriate  for  a  subject 
administrrtor  to  allocate  user 
clearances,  define  which  roles  a 
user  may  assume  and  specify  which 
department  he  or  she  belongs  to. 

It  is  also  appropriate  for  an 
object  administrator  to  determine 
an  object's  ACL  entries  and 
security  classification. 

5.3.4  There  are  three  levels  at 
which  standardization  might  be 
appropriate: 

Level  1  -  Define  standard  protocols 
for  the  passing  of  subject-relaled 
privilege  attributes,  confirming 
the  definition  to  include  only  the 
means  of  protection  and 
certification,  the  occasions  when 
attributes  are  transmitted,  and  how 
they  are  obtained. 

Level  2  -  The  definition  of  a  set 
of  standard  attribute  types  within 
which  the  values  used  in  real 
systems  will  fit  (Ref  5) . 

Level  3  -  A  set  of  standard 
attribute  values  common  to  all 
conformant  systems. 

Level  1  standards  would  seem  to  be 
generally  useful.  There  are 
parallels  for  Level  2  standards 
within  the  Directory  proposals  of 
OSI  and  CCITT  (Ref  10) ,  and  a 
degree  of  commonality  with  these 
would  be  of  value.  Level  3 
standards  may  be  appropriate  for  a 
few  widely  used  attribute  types, 
particularly  as  used  in  protocol 
interactions  with  and  between 
security  support  services. 

5 . &  Mandatory  versus 
Discretionary 
authorization  policies 

A  mandatory  authorization  policy  is 
often  defined  as  a  policy  based  on 
security  labels,  with  users 
possessing  clearances  like  SECRET, 
and  orotected  objects  possessing 
similarly  named  classifications 
(e.g.  Ref  13) . 


A  discretionary  authorization 
policy  is  in  contrast  thought  of  as 
a  policy  based  on  individual  user 
identity,  with  users  being  granted 
or  denied  access  on  the  basis  of 
who  they  are  rather  than  what 
clearance  attributes  are  associatea 
with  them. 

Under  the  authorization  framework 
of  this  paper  these  differences  are 
revealed  as  sriperf  icial ;  the  labels 
of  the  mandatory  policy  and  the 
subject-user  identity  attributes 
associated  with  capability  or  ACL 
approaches  are  merely  variations  on 
the  same  theme.  Indeed,  if  under  a 
mandatory  policy  users  possessed 
unique  non-hierarchic  individual 
caveat  clearances,  the  clearances 
become  equivalent  to  user-id's  and 
the  corresponding  classifications 
simplified  ACL  list  entries. 

Another  distinction  drawn  between 
mandatory  policies  are  centrally 
controlled,  in  contrast  to  the 
discretionary  policy  approach  of 
control  by  ownership.  In  terms  of 
the  concepts  of  this  paper,  the 
difference  lies  in  the  allocation 
of  access  to  the  privilege  and 
control  attributes  treated  as 
projected  objects.  Looked  at  in 
this  way,  it  b?  corn.  0  s  apparent  that 
a  variety  of  choices  of 
devolution/centralization  of 
control  is  possible,  depending  on 
the  authorization  policy  associated 
with  the  attributes.  This  reflects 
the  real  world  requirements 
exemplified  by  security  manager, 
sub-manager,  department  manager, 
team  leader,  or  individually  based 
control  policies. 

A  third  difference  drawn  between 
mandatory  and  discretionary 
policies  is  that  of  rigor.  In 
general,  mandatory  policies  are 
expected  to  provide  stronger 
protection  for  two  main  reasons: 

-  mandatory  policies  are  usually 
implemented  within  an  architecture 
which  makes  a  clear  distinction 
between  trusted  code  and  untrusted 
code.  Policy  control  is  ensured  to 
be  exercised  only  via  trusted  code, 
making  evaluation  easier  and  the 
level  of  assurance  consequently 
higher-. 

-  mandatory  policies  incorporate 
the  concept  of  flow  control 
(exemplified  by  the  ‘-property  of 
Ref  14,  but  more  generally  treated 
in  Ref  15) .  This  protects  the 
system  from  malicious  leakage  of 
sensitive  data  to  less  sensitive 
environments  by  untrusted  'Trojan 
Horse'  code. 
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In  principle  however  there  is  no 
reason  why  a  discretionary  policy 
should  not  incorporate  such 
features;  in  practice  it  is 
operational  flexibility  that 
determines  the  acceptability  of 
constraining  the  software  contexts 
within  which  control  over  the 
policy  is  exercised,  and  it  is  the 
granularity  of  the  authorization 
policy  that  determines  the  ease  or 
difficulty  of  policing  information 
flows  in  a  way  which  retains  an 
acceptable  degree  of  usability. 

6.  RELATIONSHIP  TO  THE  POD 

EVALUATION  CRITERIA _ 

(Ref  13) 

It  is  not  the  task  of  the  ECMA 
group  to  lay  down  criteria  for 
assessing  the  strength  of  security 
in  a  distributed  system,  but  the 
framework  does  provide  a  basis  upon 
which  such  standards  could  be 
constructed.  The  major  aim  of  the 
work  however,  is  the  definition  oi 
standards  which  will  make 
independently  designed  network 
components  able  to  work  together  in 
a  secure  manner. 

The.  authorization  model  shows  that 
the  concept  of  mandatory  versus 

discretionary  control  is  an 
oversimplification;  there  is  a 
complete  spectrum  of  approacnes  of 
which  the  policies  described  in  the 
DoD  criteria  are  only  two  examples. 
Reference  9  lends  further  weight  to 
this  point. 

In  other  respects,  the  framework 
and  the  detailed  standards  that 
grow  from  it  will  where  relevant  be 
developed  to  be  compatible  with  the 
DoD  criteria.  The  ECMA  group 
regards  the  DoD  criteria's 
requirement  to  separate  trusted 
code  from  untrusted  code  as  being  a 
fundamental  one,  and  the  framework 
helps  to  define  this  separation  by 
enabling  trusted  code  functions  to 
be  identified  and  categorized, 

7.  CONCLUSIONS 

The  paper  has  described  an 
application  layer  security 
framework  which  enables  a 
distinction  to  be  drawn  between 
network-wide  and  local  application 
security  policies.  A  set  of 
elemental  security  facilities  has 
been  defined  and  an  example  given 
of  how  these  can  work  together. 


Reference  12  includes  a  section  by 
TG9  which  sows  some  of  these 
facilities  combined  into  possible 
standard  security  applications. 

This  work  is  continuing  within  TG9 , 
and  the  group  is  looking  towards 
the  definition  of  standard 
communications  protocols  to  and 
between  standard  security 
applications. 

The  paper  has  also  described  an 
authorization  data  structure  which 
supports  a  variety  of  authorization 
mechanisms  ranging  from 
capabilities  through  label-based 
schemes  to  ACLs.  It  forms  a  basis 
for  moving  forward  to  develop 
standards  relating  to  the  kind  of 
authorization  data  that  is  required 
to  be  passed  between  application 
entities  in  order  to  support  their 
access  control  policies. 
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APPLYING  THE  ORANGE  BOOK  TO  AN  MLS  LAN 


Dan  Schnackenberg 


Boeing  Aerospace  Company 
Mail  Stop  87-06 
P.O.  Box  3099 
Seattle,  WA  98124 


This  paper  presents  an  overview  of  Boeing’s  multilevel 
secure  (MLS)  local  area  network  (LAN)  and  a  discussion  of  the 
issues  that  have  arisen  from  applying  the  DOD  Trusted 
Computer  System  Evaluation  Criteria'  (commonly  called  the 
"Orange  Book")  to  this  MLS  LAN.  Our  MLS  LAN  has  been 
designed  and  developed  to  meet  the  A1  criteria  of  the  Orange 
Book,  interpreted  for  a  local  area  network,  and  is  currently  under 
developmental  product  evaluation  with  the  National  Computer 
Security  Center  (NCSC).  A  three  node  system  is  operating  in 
our  development  laboratory  to  support  integration,  testing,  and 
addition  of  new  capabilities.  This  three  node  system  utilizes 
prototype  hardware,  however,  the  initial  product  package  is 
currently  under  development. 

Our  developmental  product  evaluation  with  NCSC  began 
in  late  1985  using  the  Oiange  Book  as  guidance  in  lieu  of  a 
network  criteria.  The  current  evaluation  approach  is  to  use  the 
draft  Trusted  Network  Inteipretations  ONI)2.  In  applying  these 
interpretations,  ensuring  data  integrity  and  preventing  denial  of 
service  become  issues. 


MLS  LAN  OVERVIEW 

Ou.  MLS  LAN  is  unique  because  of  the  number  of 
services  provided  within  the  LAN.  Figure  1  illustrates  the 
jbjectives  of  the  MLS  LAN  program.  The  MLS  LAN  provides 
both  a  back-end  (host-to-host)  network  and  a  front-end 
(terminal-to-host)  network,  as  well  as  interfaces  to  analog  video 
and  high  bandwidth  digital  stream  (e.g.,  digital  sensors)  devices. 
Wavelength  division  multiplexing  is  used  on  the  fiber  optic  trunk 
to  support  simultaneous  transmission  of  digital,  amlog  video,  and 
stream  data. 

The  current  capabilities  include- 

•  Interterminal  communication 

•  Terminal-to-host  communication 

•  Reliable  host-to-host  communication 

•  Host-to-host  datagram  service 

®  Control  of  the  physical  circuit  switching  for  analog 
video  and  high  speed  digital  devices 

•  Comprehensive  network  management 
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Figure  1:  MLS  LAN  System  Diagram 
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Future  product!)  are  in  varying  stages  of  development. 
They  include- 

•  File  transfer  support 

•  Simple  Mail  Transfer  Protocol 

•  End-to-end  encryption 

•  Gateway  to  the  Defense  Data  Network 

•  MLS  LAN  bridge 

•  Alternate  media  access  methods 

•  Extensive  voice  services 

•  Network  mail 

•  File  server 

•  Database  server 

•  Printer  server 

The  system  is  based  on  the  DOD  protocol  suite,  with  full 
protocol  support,  within  the  LAN  for  TELNET,  Transmission 
Control  Protocol  (TCP),  User  Datagram  Protocol,  and  Internet 
Protocol  (IP).  The  IEEE  standard  802.4  token  bus  protocol  is 
used  at  the  link  layer. 

The  MLS  LAN  provides  controlled  access  to  the  network 
medium  by  a  variety  of  devices,  including  terminals,  hosts, 
workstations,  tutd  video  and  stream  devices  (and  eventually  voice 
devices,  printers,  tapes,  and  disks)  all  within  a  multilevel 
environment.  Our  network  manure utem  wuiksiduun  piuviuc^ 
centralized  management  of  the  network,  while  the  Secure 
Network  Servers  (SNS)  provide  protocol  processing  and  access 
control  for  the  attached  subscriber  devices.  Each  device  can  be 
configured  to  operate  within  a  range  of  sensitivity  levels;  and 
terminal,  workstation,  and  host  interfaces  can  be  configuied  to 
support  multiple  concurrent  sessions  each  operating  at  a  different 
sensitivity  level. 

Within  each  SNS,  a  significant  amount  of  software  is 
required  to  support  the  range  of  user  and  security  services.  One 
of  the  A1  design  objectives  is  to  minimize  the  size  and 
complexity  of  the  network  trusted  computing  base  (NTCB).  To 
meet  this  objective,  the  software  within  the  SNSs  is  partitioned 
into  both  NTCB  and  non-NTCB  components.  Non-NTCB 
software  provides  protocol  services,  including  TELNET,  most  of 
TCP,  and  most  of  the  host-to-SNS  protocol.  Non-NTCB 
protocol  funct'ons  provide  many  of  the  data  integrity  features 
addressed  in  the  TNI.  The  NTCB  functions  ensure  that  non- 
NTCB  processes  supporting  different  user  sessions  cannot 
inierfere  with  each  other.  Reference  3  provides  a  mo.e  detailed 
description  of  the  software  security  architecture. 

APPLYING  THE  TNI 

In  applying  the  criteria,  our  MLS  L.AN  is  evaluated  as  a 
single  component.  The  MLS  LAN  comprises  multiple  devices: 
one  or  more  SNS  and  a  network  management  workstation.  Each 
SNS  contains  one  or  more  microprocessor.  None  of  these 


devices  meets  the  A1  criteria  by  itself,  however,  the  MLS  LAN 
as  a  whole  provides  the  features  necessary  to  meet  the  A1 
criteria.  Most  of  the  A1  criteria  apply  directly,  without 
significant  interpretation,  to  our  MLS  LAN.  The  following 
paragraphs  discuss  issues  arising  from  the  application  of  those 
criteria  requiring  interpretation. 

Discretionary  Access  Control 

In  formally  mapping  the  features  of  a  packet-oriented 
network  to  a  Bell-LaPadula-like  model4,  discretionary  access 
control  maps  nicely  to  the  requirement  for  correct  addressing  and 
delivery:  only  the  sender  of  a  packet  and  his  protocol  processes 
are  permitted  to  write  the  packet,  and  only  the  addressee 
designated  by  the  sender  and  his  protocol  processes  are  permitted 
to  read  the  packet.  The  packet  source  and  destination  map  to  the 
discretionary  access  control  matrix  of  the  mode!  for  the  packet 
object.  In  a  connection-oriented  system,  the  connection  can  be 
viewed  as  the  object.  For  duplex  communication,  both 
participants  in  a  TCP  connection  or  TELNET  session  (and  their 
protocol  processes)  are  permitted  read  and  write  permission  to 
the  connection  object.  One-way  communication  is  achieved  by 
providing  one  of  the  participants  with  read-only  access  to  the 
connection.  This  approach  is  used  in  our  network  to  provide 
data  transfer  from  lower  security  levels  to  higher  security  levels. 

TCP’s  fully  specified  passive  open  provides  an  additional 
discretionary  access  control  mechanism.  The  process  requesting 
a  passively  opened  socket  may  specify  a  remote  socket, 
indicating  tna:  the  requesting  process  wishes  to  only 
communicate  with  the  remote  process  connected  to  the  specified 
remote  socket.  Our  network  supports  this  feature  and  also 
permits  the  requesting  process  to  specify  the  remote  host  without 
specifying  the  full  remote  socket.  This  is  an  extension  to  the 
TCP  upper  layer  protocol  interface  supporting  a  capability 
similar  to  the  specification  of  user  groups  for  discretionary  access 
control  in  operating  systems.  The  NTCB  services  passive  and 
active  open  requests,  and  provides  the  addressing  and  delivery 
functions  at  the  link,  network,  and  transport  layers,  which  meets 
the  interpreted  requirements  fot  discretionary  access  control. 

For  our  physically  circuit-switched  services,  we  provide 
standard  discretionary  access  control  mechanisms.  Users  control 
circuit-switched  devices  and  channels  through  the  network’s 
terminal  interface.  Users  may  request  ownership  of  devices  and 
channels,  and  may  request  that  devices  be  connected  to  channels. 
When  a  channel  is  allocated  to  a  user,  the  user  is  given  the 
opportunity  to  specify  a  discretionary  access  control  list  for  the 
channel.  This  list  identifies  the  set  of  users  permitted  to  connect 
receiving  devices  to  the  channel.  This  mechanism  is  similar  to 
providing  an  access  control  list  for  files  in  an  operating  system, 
except  that  the  only  right  that  can  be  passed  to  other  users  is  the 
light  to  receive. 
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QbjecLikuie 

Within  our  LAN,  we  meet  the  standard  requirements  for 
object  reuse:  each  storage  object  is  set  to  a  predetermined  initial 
state  before  allocation  to  a  non-NTCB  process.  The  more 
difficult  aspect  of  object  reuse  in  our  system  is  controlling  reuse 
of  distributed  objects.  One  of  tl  objects  supported  by  our  MLS 
LAN  is  the  TCP  connection.  A  connection  is  necessarily 
distributed  between  the  two  SNSs  providing  the  connection 
object.  From  one  connection  to  the  next,  the  connection  name  is 
reused.  For  example,  if  a  connection  between  sockets  A  and  B 
is  closed,  and  a  new  connection  between  the  same  sockets  is 
opened,  the  new  connection  will  have  the  same  connection  name 
as  the  old  connection.  The  problem  is  ensuring  that  prior  to 
reuse  of  the  connection  name,  all  remnants  of  the  old  connection 
are  removed  from  the  system  ensuring  that  old  connection  data 
does  not  enter  the  new  connection.  This  problem  has  led  to  the 
development  of  a  session  management  protocol  for  initiating  and 
terminating  connections.  This  protocol  is  used  between  session 
managers  at  the  two  SNSs  involved  in  the  connection.  Session 
managers  are  NTCB  processes  that  control  access  to  the 
connection  objects.  The  major  complicating  factors  in 
supporting  this  type  of  distributed  object  are  (1)  bit  errors  cause 
lost  packets  between  the  session  managers;  and  (7)  remote  SNSs 
may  have  been  shut  down  or  reinitialized  during  the  execution  of 
the  protocol,  causing  the  session  managers  to  lose 
synchronization.  Our  session  management  protocol  addresses 
these  problems. 

LkpHikaiifla. and  Amneniicatiijn 

Identification  and  authentication  of  network  users  are 
required  at  the  terminal  interfaces  to  ihe  LAN,  however,  users 
gaining  access  to  the  LAN  through  host  computers  are  assumed 
authenticated  by  the  hosts.  Identification  and  authentication  of 
hosts  was  determined  to  be  not  essential  in  the  LAN 
environment.  An  SNS  attached  to  a  host  will  likely  be 
collocated  with  the  host,  so  that  physical  security  ft.,  this 
interface  can  be  assumed.  Host  identification  can  provide  some 
protection  against  cabling  errors,  howev  -r,  authenticating  the  host 
provides  little  assurance  that  the  host  is  ihe  expected  host  and 
has  neither  been  penetrated,  nor  replaced. 

A  more  reasonable  requirement  is  for  the  network  to  detect 
disconnection  of  hosts  and  SNSs,  and  to  forward  this  information 
to  the  network  management  workstation  for  display  to 
operational  personnel.  Our  network  meets  this  requirement, 
providing  network  operational  personnel  assurance  that  they  will 
be  notified  if  the  network  configuration  changes.  This  capability, 
plus  physical  security  measures,  provide  reasonable  assurance  of 
the  authenticity  of  a  host’s  identity. 


Trusted  Path 

Ihe  draft  TNI  requires  a  trusted  path  only  from  users  to 
the  NTCB.  This  is  supported  at  our  terminal  user  interface, 
ensuring  that  users  are  not  spoofed  by  an  application  program 
masquerading  as  the  NTCB.  For  host  interfaces,  there  is  a 
similar  problem:  the  host  needs  mechanisms  ensuring 
communication  with  the  NTCB.  This  mechanism  must  support 
communication  of  labels,  user  identity,  and  addressing  data 
between  the  host  and  SNS.  Initialization  and  dosing  of  the 
interface  ana  user  sessions  are  communicated  using  this  "trusted 
path."  The  NTCB  software  that  demultiplexes  packets  from  the 
host  implements  this  trusted  path  by  scanning  the  protocol  header 
to  determine  if  the  packet  should  be  sent  to  a  NTCB  or  a  non¬ 
NTCB  process.  By  sending  packets  with  appropriate  headers, 
the  host  is  assured  that  the  packet  is  received  by  the  NTCB. 
These  headers  are  also  used  by  the  SNS  to  mark  packets  from 
the  SNS’s  NTCB.  The  SNS  NTCB  fills  the  headers  preventing 
non-NTCB  software  in  the  SNS  or  a  remote  host  from  spoofing 
the  host. 

Audit 

Audit  requirements  in  a  network  differ  significantly  from 
those  in  hosts.  The  Orange  Book  requirement  that  "introduction 
of  objects  into  a  user’s  address  space"  be  audited  must  be 
liberally  interpreted  to  make  sense  in  networks.  For  our 
connection-oriented  services,  the  user’s  address  space  could  be 
interpreted  as  including  the  address  space  of  processes  supporting 
the  user  connection  in  the  SNSs.  This  would  imply  that  all 
packet  deliveries  would  have  to  be  audited,  creating  significant 
audit  overhead  for  the  network.  A  more  reasonable  approach  has 
been  taken,  requiring  that  connection  events  (creation  and 
termination)  must  be  audited,  but  not  individual  packet  delivery. 

System  Integrity 

For  operating  systems,  off-line  diagnostics  are  sufficient  to 
meet  the  Orange  Book  system  integrity  requirements.  System 
integrity  requirements  have  been  extended  in  tiie  draft  INI  to 
include  mechanisms  detecting  loss  of  components.  The  802.4 
token  bus  protocol  used  in  our  MLS  LAN  provides  the  capability 
for  SNSs  to  detect  loss  of  a  neighboring  SNS.  This  information 
is  forwarded  to  the  network  management  workstation  and 
displayed  lo  network  operational  personnel.  Fach  SNS  is 
responsible  for  detecting  loss  of  subscriber  devices.  These 
capabilities  support  both  the  system  integrity  requirements  and 
the  communications  integrity  requirements  of  the  draft  TNI. 

Communications  Integrity 

Our  MLS  LAN  provides  several  communications  integrity 
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features  to  protect  against  transmission  errors.  Each  SNS 
incorporates  mechanisms  providing  assurance  that  (1)  the  remote 
session  manager  initiating  the  session  is  valid,  (2)  delivered 
packets  do  not  contain  errors,  (3)  packets  for  connections  are 
delivered  in  order,  and  (4)  packets  arc  not  lost. 

Remote  session  manager  authentication  is  implicit. 
Because  die  network  can  detect  loss  or  addition  of  an  SNS  in  the 
link  layer  protocol,  each  SNS  that  is  currently  on-line  can  be 
presumed  valid.  The  security  and  network  administrators  are 
notified  when  SNSs  enter  and  leave  the  token  bus.  An  SNS 
must  be  on  the  token  bus  to  transmit  data  intelligibly.  This 
mechanism  provides  network  administrators  the  capability  to 
monitor  the  network  configuration  and  identify  the  introduction 
of  bogus  SNSs.  If  network  operational  personnel  adequately 
control  the  addition  of  SNSs  to  the  token  bus  and  physically 
validate  the  authenticity  of  SNSs  when  they  arc  brought  on-line, 
then  the  risk  of  a  bogus  SNS  (and  session  manager)  is  minimal. 

Protection  of  user  data  against  modification  is  provided 
partially  within  the  NTCB  and  partially  in  non-N  1'CB 
communication  software.  Our  implementation  of  TCP  places  the 
communication  integrity  features  outside  the.  NTCB,  including 
checksum,  timeouts,  retransmission,  and  packet  sequencing. 
These  features  provide  high  assurance  that  the  user  data 
delivered  is  the  same  as  the  data  transmitted,  assuming  that 
active  wire-tapping  is  not  present.  Additional  features  are 
provided  by  NTCB  hardware  and  software,  including  a  32-bit 
cyclic  redundancy  check  at  the  link  layer,  the  IP  header 
checksum,  and  enror-detecting  memory  in  the  SNSs,  as  well  as 
features  in  the  NTCB-to-NTCB  protocol  to  ensure  that  NTCB 
data  is  delivered  with  high  integrity. 

Currently  no  protection  is  provided  against  active  wire¬ 
tapping  threats  (e.g.,  playback  and  message  modification)  within 
our  MI.S  LAN.  The  SNSs  and  transmission  medium  are 
assumed  to  be  physically  protected.  We  plan  to  address  wire¬ 
tapping  threats  in  future  products  through  involvement  in  NSA's 
Commercial  COMSEC  Endorsement  Program  (CCEP). 

Denial  of  Service 

Denial  of  service  protection  within  our  MLS  LAN  includes 
mechanisms  for  (1)  identification  of  the  loss  of  components, 

(2)  continued  operation  in  the  presence  of  component  failures, 

(3)  notification  of  network  operational  personnel  when 
component  failures  are  detected,  (4)  on-line  reconfiguration  of 
the  network,  and  (5)  network  management  controlled  limitations 
of  resource  utilization  to  ensure  that  one  user  does  not  consume 
excessive  amounts  of  eritiea!  resources  denying  service  to  other 
users. 

Detection  of  the  loss  of  components  was  discussed  in  the 
system  integrity  paragraph.  Loss  of  a  component  affects  only 


the  users  of  that  component.  The  remainder  of  the  network 
recovers  automatically  and  continues  operation.  The  exception  is 
loss  of  tlie  network  management  workstation.  When  SNSs 
cannot  communicate  with  the  network  management  workstation, 
they  arc  designed  to  automatically  shut  down,  which  is  required 
to  meet  the  A1  criteria.  The  security  administrator  is  provided 
the  capability  to  override  this  feature  and  permit  the  network  to 
continue  in  degraded  mode  when  the  network  management  node 
fails.  This  can  be  used  in  environments  where  continued 
operation  is  more  critical  than  loss  of  audit  data.  Audit,  terminal 
user  login,  circuit-switched  services,  and  name  service  arc  lost 
when  operating  in  degraded  mode,  however,  terminal  and  host 
users  can  still  communicate  over  existing  sessions  and  can 
initiate  new  sessions  provided  the  user  does  not  require  the  name 
service  feature.  Design  of  a  hot  spare  approach  for  network 
management,  with  automatic  switch-over  is  in  progress,  but  is 
not  planned  to  be  part  of  the  initial  product. 

Several  mechanisms  are  used  to  ensure  that  no  user,  or 
group  of  users,  consumes  an  inappropriate  share  of  the  network’s 
critical  resources.  At  the  lowest  levels,  within  our  MLS  LAN’s 
executive,  a  timc-slic.ed  scheduling  discipline  is  enforced  for 
non-NTCB  processes.  This  ensures  that  each  process  has 
sufficient  access  to  the  CPU.  NTCB  processes  are  given  as 
mucii  Lime  in  inc  ci  v  as  tucy  need,  while  non-NT  CB  processes 
(i.e.,  those  supporting  user  connections)  are  provided  an  equal 
share  of  the  CPU.  Each  memory  manager  within  an  SNS  uses 
memory  quotas  to  prevent  processes  from  using  memory 
exhaustion  to  deny  access  to  other  users.  Because  multiple 
subscriber  devices  can  be  connected  to  a  single  SNS  and  the 
SNS  has  a  maximum  number  of  concurrent  sessions  that  it  can 
support,  each  subscriber  device  is  allocated  a  maximum  number 
of  sessions  that  can  be  used  by  that  device.  Terminal  users  also 
have  quotas  limiting  tire  number  of  concurrent  sessions  they  are 
permitted.  Finally,  each  SNS  is  provided  a  limit  on  how  long  it 
can  transmit  when  it  has  the  token,  ensuring  that  no  SNS 
transmits  continually,  denying  access  to  file  hunk  to  other  SNSs. 
This  "token  hold  time"  can  be  used  to  allocate  priorities  to  SNSs. 
An  SNS  is  given  access  to  a  higher  percentage  of  the  hunk  by 
being  assigned  a  larger  token  hold  time.  The  token  bus  protocol 
ensures  that  each  SNS  is  provided  an  opportunity  to  transmit. 
Each  of  the  quotas  (memory',  sessions,  and  token  hold  time)  are 
set  by  the  network  administrator  and  can  be  modified  on-line  to 
reflect  changes  in  priorities.  Loss  of  service  (denied  access) 
because  of  resource  exhaustion  is  an  auditable  event,  which  can 
lie  monitored  by  administrative  personnel.  These  mechanisms  do 
not  prevent  denial  of  service,  but  they  do  alert  administrative 
personnel  to  denied  access  and  provide  administrative  personnel 
the  capability  to  prevent  resource  exhaustion  by  single  users. 

Network  performance  data  is  also  accumulated  and 
displayed  to  the  network  administrator,  litis  provides  the 
capability  to  determine  when  components  of  the  system  arc 


becoming  overloaded  causing  degraded  service  to  users.  The 
network  administrator  can  resolve  the  problem  through 
reconfiguration  of  the  network  or  modification  of  quotas  to 
provide  tire  affected  users  a  larger  share  of  the  network 
resources. 

siAim 

The  developmental  product  evaluation  of  our  MLS  LAN  is 
nearing  completion.  Most  of  the  required  documentation  has 
been  delivered  to  the  NCSC,  and  with  the  release  of  the  draft 
TNI,  many  of  the  uncertainties  in  the  evaluation  have  been 
eliminated.  The  major  issue  remaining  for  the  evaluation  is  to 
determine  the  impact  of  the  latest  TNI  version. 

The  product  development  is  also  nearing  completion.  The 
major  remaining  tasks  are  (1)  completion  of  the  product  from  the 
existing  advanced  development  models;  and  (2)  completion  of 
product  testing.  Production  piototypes  are  expected  to  be 
completed  during  the  first  quarter  of  1988.  The  product  testing 
effort  is  underway. 
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A.  INTH()I)1<  TION 

The  modular  approach  to  the  design  ol  computer  systems  has 
hern  the  subject  ol  considerable  at  tent  inn  in  the  studv  <  *1  opei.il- 
in*;  M.stciM''  and  pro^r.oniniiij;  lanj;i|.ij.,.es.  I  uihI. iineiit.il  cliarac- 
1  er  jst  ie*-.  to  he  enlou  ed  l»\  modul.ti  i/at  ion  im  hid*1  cm  a psiila  1  ion . 
<l.i t  .1  abstraction,  s\  m  Inoni/aticm  ol  min  in  rent  aue^.  protec  ¬ 
tion  and  reliability  Such  t  har.ic  tei  I'-i  n  s  are  ol  special  iritciesi 
in  an  distributed  network  environment  since  access  to  common 
control  date  is  not  t*eurr«ill\  feasible*. 

lor  our  work  on  prolc’clion.  we  have  adopted  a  jpueral  ob¬ 
ject -oriented  model.  An  object  is  an  instance  ol  an  ahstiacl  data 
i  v  pe  in  that  it  c*t!<  si  |  »s  1 1 1  ,i  t  i*s  object  vaiiaHc"*  and  opera!  icm-  on 
these  variables.  The  object  variables  have  an  indefinite  lifetime 
and  ma\  be  shared  in  a  c  oiiimiinilv  ol  users.  Opei  at  ions  on 

I  he-a*  object  variable's  arc*  performed  llnoimh  tin*  invocation  ol 
procedures  which  ate  exported  b\  all  objec  1 .  I  Ins  is  the*  onlv 
means  ol  inter  -  objec  l  communicat  ion.  I'oi  purposes  ol  this  dis¬ 
cussion.  a  uudei  line  leh.ible  multilevel  securitv  message  passing 
Msiem  is  assumed  to  exist. 

Two  1  V  pes  ol  sec  in  it  ies  ale'  rommonlv  considered :  a<  <  ess  c  on- 

I I  <>l  and  inloi  mat  ion  How  control.  -\n  acc  ess  emit  ro!  poliev  spec- 
ilic's  .tut  hor  i/at  ion  lot  access  to  objects  b.ised  on  the*  idem  it  v  ol 
siil>je<ts.  |  nioi  mat  ioli  How  jiolrc  \  regulates  the  How  ol  mioi  illa¬ 
tion  bet  ween  c  I  ass  died  objec  ts.  \\  hile  a  syndic  ant  amount  ol  re- 
sea  i  c  1 1  ha-  heeii  done  on  inloi  mat  icm  flow  c  out  rol  2.S  .  the*  lc*t  i»s 
ol  attention  in  this  paper  is  on  the  rn.innei  in  which  information 
How  polic  ies  can  lie*  enloictd  in  an  objec  I -orient ed  distributed 
c'nv  ironmem . 

Since*  1  lie  various  objects  of  program  ruav  be*  j;eo£i aphic  allv 
tlisi  r  ihiiled  or  c  oust  rue  tod  at  different  points  it,  time,  it  ma> 
not  In*  feasible  for  one  objec  t  to  ace  ess  protect  ion  inloi  mat  ion  of 
olhej  objects.  Instead,  it  is  desir  able  to  establish  I  he  “internal*’ 
inloi  mat  ion  How  securitv  ol  eae  li  procedure  in  an  object  inch* 
pendent  ol  other  pi  oc  ed  ures  and  olhc'i  objc'cts.  Since*  this  does 
not  account  for  inter -objec  t  flow  ol  information,  the  securitv  of 
a  program  must  be*  partiallv  ceitiiied  at  mu  lime  To  be  usrlnl. 
t  his  c  eit  die , it  ion  nm-a  be*  .iImi  c*l!i<  ieiit 

I  In*  method  presc-nted  in  1  Ills  paper  is  a  *  ombmed  ..ppioac  h 
ol  c  om [ale  t  uric*  .md  tun  I  him*  iiif* M  in.il  roll  tl«»w  <  <  i  I  die  at  mu.  I  he 
celojale  time  1 1 n<  lla  1 1 1- 1 n  e-  1  ,t bli- lies  1  |i«  iiit<liial  mthmIv  o|  iri 
djv  nbi.d  pi  oc  c*d  in  es  a  in  I  c  l  ea !  c  -s  \  hr  nn  e-  -  a  i  \  ml*  u  lua  t  h  »n  -1  i  in 
t  in  i*s  t  o  a  I  low  lor  el  lie  lent  ;  u  n- 1 :  r  r  i«  -  t  \  1 1  iln  .it  mil  ol  mi  *  i  <>!■  |«  i  I 
<  *  mi  i  mime  at  ion.  |  he  Min  linn  inn  Ii.immii  i  oinpli  It  -  I  he  : «  i  l  di 
(  at  l<Mi  i  tf  1 1n  cut  il  e  |U  o*;l  am  .it  me*-  s.,mi  pass]  i,j.  1 1  or  h\  Vi  id  \  me 
tin*  i  il  (m  mat  n  mi  I  low  i  a  Used  l>\  pio<  i  dure  invoc  at  n  Mi'¬ 


ll.  A  DKMMTION  Ol  FLOW  (’ON  I  KOI. 

I'ln*  uiicb*i  Iv  iri£  t  ln*or>  ol  mformat  ion  How  e  out  rol  is  based  on  l  he 
lattice  tnodei  (SC.  •  -.  :•  )  introduced  bv  Demiinj;  d  .  where 

1.  SC  is  a  finite  set  ol  securitv  c  he-M’s; 

2.  is  a  biiiarv  relation  which  induces  a  pai  i  i.d  ordering  on 
1 1re  sec  ui  it  v  <  lasses  in  S( 

d.  is  aii  .issue T it  ive  «i l r <1  cemmiuiat  ivc  binar  v  opeiatcir  on 
SC.  ch'iiol  in*;  the*  least  upper  bound,  r.j;  A  ■  H  is  the* 
least  upper  bound  o|‘ ’securitv  classes  A  and  It;  and 

1.  is  an  associative*  and  commutative  binarv  operator  cm 
S<  demit  im;  I  lie  greatest  lower  bound,  e  g.  A  .*:  It  is  the* 
l>  lea  test  low  ei  bound  ol  securitv  classes  A  and  It. 

■V  S( '  lias  t  he  greatest  lower  bound  IA)\V  and  tin*  least  upper 
bon  id  MICH  such  that  LOW  A  and  \  1 1  Kill  lor  all 

A  in  SC. 

For  liotationai  convenience*,  il  \  is  a  variable,  then  the  securitv 
c  lass  of  x  vviil  be  denoted  bv  x. 

An  example  ol  tin*  use*  ol  such  a  securitv  lattice  occurs  in 
militarv  organizations  where  a  -ec  uritv  <  lass  js  c  ommoulv  desi** 
naled  as  an  ordered  pair  (classific  at  ion,  dc'parl  nient ).  lla  and  b 
ai  «*  c  lassibc  at  ions  ol  i  ufoi  mat  ion  I  \(  1. \SS|  I-  1 1*.| ).  (  T  )\- 

I  11  H  M  l  \b.  Sl-.Cin-  T.  TOrxI.CKKT)  and  \  and  v  ale  «  cun 
pallmelits  ( r  epr eselil  1 11$;  need  to  know),  then  the  pai’ial  cMtlcl 
ol  tin*  sc-c  i|  t  1 1  v  c  hisses  ix  deliued  bv 

(a.x)  (b.v)  il  and  o 1 1 1 v  d  <i  b  and  X  \. 

Ibe  poliev  tAovc-iimij;  secure  imI<m  in.i  i  nm  flow  i-  determined  bv 
the  securitv  lattice  for  simplicity  t  lie  exa  mph*s  m  tins  paper 
assiirnc*  a  lineal  l<it  tic  e  of  sec  lint  v  c  hisses  <  c>usi-i  inj;  ol  I  \Cl  \s- 

S If  1 1 , 1 )  (  how  ).  COM  IDKM  I  \h.  sl-.CK I  T.  T( )l,s|-.(  HWY 
[  MICH). 

A  proj;i  am  variable*  mav  be*  either  static  allv  or  d\ mimic  allv 
bound  to  a  sec  iji  i  1  \  class.  A  ‘statu  allv  bound  variable  i-  as¬ 
signed  a  fiMi!  securitv  class  at  the*  lime  ol  its  dehinlion.  file 
securitv  cl.es  of  a  “d\ Damn  alb  bound  valrablc*  c  barites  with 
t  be  c  lass  o|  it  x  ussc  u  Ml  ed  i  nloMi  la  1  i->ri  An  i  u  Icm  inal  ion  I  low  1 1  om 
vain tide  \  to  vailable  It  is  denoli'd  In  \  -  |t.  Il  |t  |x  ,j  -tal 

n  allv  bound  Variable,  tin’ll  mii  Ii  a  l|c»v\  is  sec  lire  d  and  ordv  il 
tin  relation  \  |i  is  impln*cl  trom  the  hit  lice.  Otherwise.  ,t 
si -c  ii r  it  v  v  n da t  ion  oc  c  u  i s.  Not e  t  ha i  d  1 1  is  a  (|  v  iia mi<  a  II \  bemud 


Viitinhlr.  M  bn  oines  A. 

Flows  t  rtit  l it'  (  hissificd  as  explicit  m  implied  An  explicit  flow 
(lorn  vai  1,1  hlrs  <i| . . . .  ,  #j„  tti  variable  \  m  (  ms  \\  lien  ;»n  r\i*<  nt  inn 

directly  assigns  inhumation  *1  i‘i  i\ 1  Imm  </, . lo  \n 

imp  l  it  il  How  from  vai  i  aides  .  iitl  i:>  oil  i.ilde  x  ot  t  in  s  w  hen 

a 1 1  exet  ul ion  ot  ii  si at  emeu  I  w  hit  l»  assigns  some  inhu  m.il  ion  to  \ 
is  cnudit ionetl  upon  values  deiixed  fiom  <i 1 . <i„.  l*oi  example. 

1  111'  St  ill  OlOt'lll 

if  <t  It  tin'll  \  :  \  else  >  :  / 

causes  .in  explu  il  llow  itoin  \  tt>  \  only  v.  Ihmi  a  t).  and  Imm  / 
to  \  only  wlii'ti  ;t  t).  Tin*  st •itciiii'iil  also  t  iuiM>  an  iuiplit  il  llow 
Irom  a  to  hot  Ii  x  and  y  regal  dless  ol  thr  'nine  ol  .i.  \oit*  that 
iinpfii  it  (lows  occin  i\<*n  in  absence  ot  execution  t»t  statements. 
This  will  In*  illiist  rat  ml  in  set  lion  |). 

<\  A  KKVIKW  or  PRKVlors  IN  FOR  MAT  ON 
FLOW  MODELS 

llilolinat  ion  flow  nnxft-is  <  ,i -i  lu*  t  hat  «u  lt»t  i/cd  by 

1.  then  ability  to  h.mdk'  statically  bound  oi  dy  nanm  ally 
hound  viii  iahh's.  and 

Z.  whether  or  not  M-cmiU  is vc-rdicd  .it  t nmpde  lime  oi  inn- 
tilin'. 

Denning  developed  it  compile-lime  tonification  procedure 
For  programs  with  statically  hound  variables  1,5.  (Titilitn- 
t  u»ii  rules  me  given  tor  each  statement  type  (*' g  n.ssigtiniiMii 
if  .statement.  while  slip eineni ,  etc.).  One  major  dilfituhy  ol 
this  approach.  however,  lies  m  handling  ol  piocedures.  Since 
tin'  class  of  idl  parameter  must  he  statically  «leciaie«).  it  dillei- 
ent  version  ol  ii  piocedure  is  required  lor  ea<  h  dillerent  m'(  uritv 
classed  (t  parameter.  This  may  not  only  h«  inc  on\ enient  hut  aho 
sevejely  impairs  I  lie  flexibility  ol  lesource  sli.ii  ing.  One  possible 
solut  ion  lor  this  problem  is  to  disallow  act  o.-s  to  global  \,u  iahles. 
I  infer  these  rest  lie  lions,  the  output  parameters  arc  line  lions  ol 
the  input  paiainelers  and  the  seiuiity  of  a  procedure  can  he 
established  by  verifying 

</ ,  ! . <irll  ’  b ,  ;e.  •  •  •  b„ 

where  </j.  ■■■,«„,  are  actual  IN  paiameteis  and  ft|,*  ■•„/»»,  aie 
act  uul  OUT  parameters  ol  the  call.  The  inability  to  e||et  lively 
handle*  object  variables  is  considered  to  be  a  major  restriction- 
In  another  model  for  dynamically  bound  variables,  Denning 
extended  Kenton's  run-t  ime  approach  (>.7,  to  art  omit  lor  im¬ 
plicit  I  lows  occurring  even  in  the  absent  r  of  the  execution  ol 
staU'inenls  i  l  .  1  he  certification  procedure  relies  on  a  liaidware 
support  meclianisiu  which  includes  a  tag  Held  in  each  memory 
cell  and  a  stack  1 1 S  which  contains  the  'etuiily  class  on  width 
I  he*  current  ly  executing  statement  is  c  urdiiioncd  {to  at  count  lor 
implicit  flows).  Tl  ie  class  on  the  top  ol  IIS  is  denoted  by  )iS. 

I  he  opelatioll  *’pu>h(e)”  plai  es  ‘  IIS  ••  v"  at  the  lop  o|  ||S  and 
the  operation  “pop”  leiiiuvi".  the  <  lass  liom  top  oi  1 1 > .  \\  hen  an 
assign  ii  w] ii  si  at  emeu' 

\  i-  i*i  i  -  -  ■  - . ) 

isexetuted.  t  he  h.:l  dw.ire  automat  it  ally  updates  \  to 
a,  •  1 1 s 

In  or  tier  !  o  at  t  omit  lor  .-mphi  it  II*  >v\  -  w  Im  h  tit  t  in  in  l  he  a  hs,»ni  e 


ol  l lit'  execution  o|  sialeini'iits.  the  compile  lime  met  h.im-  ni 
must  al-o  ni'-eil  into  I  he  sou u  e  ptogi  am  “update  h  n|u  i  at  ion**, 
w  hit  h  update  Its  m  *'l>  M's”.  I’m  example,  the  stateineul 

if  e  t  lien  S  |  else  S ‘2 
is  t  (  a  iis|o)  Hied  to  the  t  ode 

push  (e) . 

if  e  t  In'll  S  |  else  VJ  : 

loi  \  m  ((\  I  1  \  1)  (\  I  \  J))  do  update  \. 

pop. 

whole  \  1  and  \  2  are  sets  ol  vaiiaMrs  to  whuh  v.ilui’s  are  ,is- 
signed  in  SI  and  SJ,  respet  t  ivelv .  1  lie  inndt'l  to  lies  on  a  t  uinpilr 
time  analysis  to  insert  push,  pop  and  update  operations  and  on 
ru  n  t  mie  li.u  «Kv  are  to  maim  am  l  he  si  at  k  IIS  and  1  ag  fields  in  the 
memory  tells.  The  dl awhack  to  this  appmatli  is  th.it  it  letpiires 
special  art  hitet  t  in**  ami  uu  urs  sigmfn  a.nt  run  lime  cn  er  head . 

Andit'Ws  ami  |{citman*s  de\elope«t  a  compile  time  tvrtilna 
lion  teclumpie  based  on  ptogiam  \  ci  i  I  it  .it  ion  I  .  Implicit  flows 
.ire  classified  into  two  types;  local  How  and  global  flow.  A  |o 
tal  flow  is  an  implit  it  How  within  a  statement.  A  global  llow 
im  hides  an  implicit  Dow  from  t  lie  t  ondil  ional  variables  ol  an  it 
elation  statement  to  all  subsequent  statements  and  aKo  a  flow 
caused  l'\  piot  t-ss  s\  nc  luolii/alion.  I  oi  example.  1  lie  sequem  <’ 
of  statements 

X  :  0. 

\v  bih*  y  l)  do. 

\  l. 

tame-  a  gltilial  flow  limn  V  to  \  sim  t*  the  last  sialetnelil  is  ton 
tbtioliallv  exet  uied.  depend  nig  on  the  value  oi 

Ill  oi  <le;  to  handle  I  ht*sc  two  tv  pes  (>l  llow  s.  spec  i,d  t  nt  iti<  a 
1  ton  \ai  labli-s.  lot  a  I  and  glided,  are  iiilioiliit  nl.  \  value  m  !ni  a  I 
I *et  (lines 

loi.d  ]  e\p 

within  *t  conditional  statement,  where  exp  denotes  the  i  lass 
ol  the  conditional  expression.  I  pen  completion  ol  the  toudi 
lional  statement,  the  value  in  local  reverts  to  its  pn-vioijs  value. 
(  ih  dial.  <m  t  he  ol  hei  hand .  i  epiesents  an  ace  u  inul.it  ion  ot  ( l.tssi*s 
ol  the  toliditior.s  whuti  wmdd  he  in  (fieri  upon  completion  ol 
the  execution  ol  body  ol  ,i  while  statement  oi  wait  statement, 
l  or  example,  global  bet  tunes 

exp  lot  «d  global 

imi'ietlial ely  after  «i  while  statement.  Note  that  global  attu 
mill. ites  not  only  e\  >  1  lst»  local  in  urdei  to  aitoimt  toi  the 
case  in  which  the  while  slatemeiii  it  sell  is  nesttxl  within  ot  hei 
t  ond it  imial  st  aleiiu'iits 

My  using  these  t  erl  ilicat  ion  variables,  piool  Miles  are  pre¬ 
sented  lor  various  types  ol  statements,  hie  hiding  sy  lit  Inoni/a- 
5  ion  statements  (e.g.  wait  and  signal).  Yar  i.ihles  may  he  eil  liei 
statically  oi  dynamically  hound  The  verification  ol  a  pioiedme 
invoi  at  ioi:  it  tpiires  previous  veritiftil  ion  ol  l  he-  body  ol  i  he  <  ailed 
plot  ed  ii  re  and  pr«'V  ions  esl  ablislt  i  n»'!tt  <d  Mu'  pie  posit  ond  it  ions. 

Andrews  and  Kelt  man  v  mode  i  mtiii'-  too  ■  «*si  r ic-| i v lor  gel* 
ei.d  d'etribuled  object -orteir.ed  systems  in  which  dynamic  link 
ing  is  allowed  A  1st',  the  manner  in  which  self  mutual  leuitsive 
tails  are  verified  is  not  clear.  Koi  tun  nuajel.  we  need  a  certih 
cal  ion  i.i**»  ha  ii  e  ii  \\  liic  h  <  « .  1 1  verily  the  ’’internal**  security  ot  an 
object  independent  of  other  called  t>hje«  ts,  mmiic  ;»i  which  may 


m 


? 1 1 >1  W  I  hrirililird  oi  loi  \\  hit  |i  svt  ill  1 1 \  i 1 1 1 « 71  fii.it  ion  h  iu»l  \rl 
uv  in l.i i il<‘ 

1).  T1IK  INFORMATION  FLOW  Mli(  TIAN1SM 
I.  Overview 

'l  ln'  ini'!  hod  prrsrnted  in  this  paper  ,ismi mcs  d>  ii.nnu  mil  time 
link  111]',  ill  inter  oli|C(  \  |>{  ih  riline  i  alls.  Ohio  1  \ul  iuhlrs  air  as 
sullied  In  Ih*  si  at  ii  all)  lion  ini  w  li  dr  oi  hrr  \  *i  I  inldrs  iua\  l»r  rit  her 
vi.iiii-.ill>  oi  i|\ 1 1  «i  1 1 1  i<  all)  I  ion  ini  In  i  ino’d  j'l.iilii.il  <i ;  •  |  >  1  i<  a 
lions,  ihis  i»,  ,i  ir.ison.ililr  rest r i<  1  ion.  In  addition.  vvr  s«*(>h  mi 
rflii  irnt  method  1 1 i.t !  prrlornis  as  min  li  <>l  l  hr  cri  l  ihi  nl  ion  woik 
iis  possible  ,i t  i  oinjidr  1  Mill’  «iliil  oil**  \\  111*  h  dors  not  irlv  on  ''po¬ 
ind  <in  Into  l  in  <il  lf.il  »ir«*s. 

\\r  .issuinr  1  ho  Inllow  illj;  s\  nt  ,i\  |oi  ,i  pioirduir  iiiv nt  at  mil 

si utemenl : 

proicdiur  l*K(X  (IN  j-j . j,  Ol  Ti/|.  ...//„) 

wlu’lr  thr  IN  pa  I  <i  tin’ll*!  s  ,in*  "t  ,i  1 1  li\  Value  «itid  I  hr  oit 

ptii <n i n't i  I v  ,i ! r  iallh\  U’snll". 

Oui  ii  n*i  hod  ini  orpin  .ill's  iiml  extends  ideas  liom  liolli  l)rn 
nine's  inn]  \ nd row s  iind  Kri!  man  s  appioai  hrs.  Its  s, limit  lea- 
t  in  rs  <i  i  r: 

I  Object  \  iiii.ddi  "'  <irr  statii  nll\  hound.  The  i  lasses  ol  oi  hrr 
proj’iam  variables  rail  either  hr  u\ u. unit  all)  or  siaijcalh 
hound  in  oidri  1o  eliminate  ihr  lin’d  lot  inorr  than  onr 
version  ol  <m  exported  proirdnir. 

'2.  Kuril  pioinhirr.  exported  h\  ;m  ohjri  1 .  rail  In-  louipilrd 
it ud  its  “inter  iiiil"  snunH  esi.ihlished  independent  ol  oi  hrr 
pioi  riluies. 

«(.  For  rlliiieniv,  ruu-1  imr  informal  ion  llow  snuritv  i  lin  ks 
u f r  performed  onl>  at  inessaue  passiuj;  limr. 

■1.  Sinrr  ohjri  1  v.iii.ddrs  of  an  ohjrt!  have  a  lihTmtr  winch 
may  exceed  that  ol  individual  pio^rmns  i Iml  tail  a  pioir 
il in r  i’\ poi tod  hy  1  in*  ohjri  t ,  iiilorin.it  ion  (low  rout  rol  t  ;ikrs 
into  arrount  1  hr  srrnri1>  i  l.issrs  ol  these  ohjeit  v.uiahlrs. 

( >  1 1  t  p.i  i  .i  ini’!  rrs  of  an  exported  procedure  .»rr  not  .is- 
suiiird  to  In*  <i  linn  t  ion  ol  only  IN  parameters.  1  hat  is  r;n  h 
our  p.i i a  meter  n li^lil  act  ii.dk  hr  a  function  ol  miiiic  suli 
m'I  ol  thr  IN  paiamrlrrs  and  thr  object  variables  ol  this 
and  ol  !iri  ohjrrts  w ti ii  li  are  subsequent l>  tailed. 

In  order  to  at  hirer  1 1ll's**  objectives.  wr  use  a  combined  lompile- 
timr  and  run-time  nirthod.  At  rntnpilr  timr.  ihr  internal  se- 
<  nril\  of  individual  procedures  air  established  ami  thr  data 
st  i  ui  t  in  rs  nsrd  loi  rtlu  iint  inn  t  Hi  m'  «  ri  t  ifi<  iit  inn  ol  int  rr-ohjrrl 
i  oiniimtl  it  iit  ion  <trr  j»riiri  alrd.  Ihr  i  rrtilii  at  ion  ol  thr  entire 
program  is  lonijdrlrd  .it  message  piis^mj;  tinii-  h\  vei  living  thr 
inhumation  llow  caused  bv  pioi  rdtnr  iiimh  alioiis. 

I’lioi  to  r\pl« iiliinj;  thr  nirthod.  wc  f i r *  1  ideiiliiv  al!  pir.si 
Idr  input  a  k  1 1 1  output  \  <1 !  ill's  to  from  a  pioirduir  in  an  ohjri  t. 
We  define  t  lie  trim  “input  vaiiables'*  and  “output  vaii.ihlis**  to 
stand  loi  vnii.ihli’s  which  eaiiv  input  \alurs  to  lhi*  pmirdmr 
am!  output  Nalurs  horn  thr  proirdnir.  tespriliveU 
iV-siide  input  \arinldrs  i>l  a  pioirduir  I’liOr  air: 

0)  loi.ual  IN  parameters  ol  l*|{CK’. 

(  2)  the'ibjeil  variables  read  hv  FIH)(  *.  that  is  1  hr \.tlurs  ol  thr 


ohp't  t  \  •>  1 1 a ldi  *»  w  li -••n  t  hr  <  ;d  1  is  i a  Mu n 1 1 a l  i*d .  a  t id 

(.**)  ,u  t  ii.il  Ol  T  p.i  i  .u  nr  tors  i  ri  m  nnl  1 1  oni  r\  l  n  n.d  pioi  «*d tires 
t  hiit  air  i  a Ih  d  h\  I’ll  Ot 

| \v,sihlr  out  p ::  t  \  ii  i  i.thlrs  oi  I’KtX'air 

(•i)  lortnal  Ol  ]T  pal  .mirtris  o|  IMKH*. 

(,r»)  1  hr  ohjn  I  V.uiahlrs  w  i  it  tru  h\  J*K()(’,thal  r  I  h«  Vidursol 
throhji'il  vmi  iuhlt's  wlirii  thr  tall  triimnatrs,  and 

{•>)  aitiiid  IN  par  mirl ri s  toi'Xpoftril  puurdurrs  in  othi'f  o*' 
jri  1*-  th.i1  all*  rallrd  l>\  I’liOl  . 

I  lir  puiposi*  nl  thr  <  ompilr-t  mu'  al^oiithiii  is  to 
1'ijiiat  io*i  s  l  li.it  rxpri’ss  1 1n*  pot  nil  i.d  i  mi  l  imr  in  loi  mat  ion  llow  in 
s\  mholii  !<>r  iii  In  oi  drr  1  a  *]:#  t  iiis.  “s\  liihoiu  \  l.iss  t'Xpl rssions 
an  y*iiirratrd  lur  v.ir-ahlrs  in  irims  o:  ihr  i  las-rs  of  ihr  input 
v.uiahlrs  (I)  (.!)  \  s\n  holn  i  lass  rxpirssjpn  irpirsrnls  tlu- 

i  !.i  .s  a!  inhn  iii.il  mu  in  Irt  lns  o|  :  hi*  i  lassr*,  o|  v.ui.ddrs  I  Dili 
\\  liii  hit  isiomuoMil  loi  rx.miplr.  thr  il.-sso|  mioi  naif  ion  in 
t  ill*  r\pM'ss|v:|i 

a  *  n  -  r  i)  i; 

is  s\  mholii  iillv  drnotrd  In 

A  :  II  ('  >  I)  K. 

'Hir  i  lassrs  ol  dv  ii.uiiirallv  hound  input  x.iriahlrs  <  annol  hr  dr 
trriuinrd  uni  i I  inn  t  mir  During  <  onipil.it  ion .  i  lir  i  lussrs  ol  t In  si* 

i  1 1  p  ii  t  V  .1  riid.M  -  tit  t  'Si.ihiisiit-t!  .1  ""ttiiriiV  V  <•  i  i.i  hit  i|  f  i  t  » 

Viirialdrs  arr  s\  mholii  allv  drnolrd  l»v 

1  pioirduir  n.imr.v.iiiahlr  iininr 

{lor  loi  :n, d  IN  p.iralui’t  rrs  ol  ihr  pioirduir  hriiij;  i  olii 
pih'd).  or 

*J.  ohjrrt  na u ir. prot  rd  u  H'  iuiinr.v«iriah|r-n.'  me 

(for  iiilii.il  OUT  p.u  cinirtris  ol  rxtrmal  pioirduirs). 

|  or  example,  if  I  hr  proi  rdnir  hrilij*  «  ohipilrd  is  !*  ( 1  N  a.  h).  I  lu  ll 
t  hi' i  liisM’s  o|  “a"  and  “h”  an*  s\  mholu  allv  drnolrd  l»v  K.a  and 
|\h,  ri’spri  t  i  vrl\ .  Also,  if  tins  proirdurr  invokes  a  juninfurr  (• 
of  <ii i  ohjnt  O  ii-'  ().C(IN  \.  OUT  >.  /).  tin1  i  lussrs  id  \  and  / 
arr  symholn  all)  driiotnl  h\  0.(i  >  ami  0.(1./,  rrspn  1iv«  l\ . 

H.isrd  on  1  hrsi'  s\mhi»lii  <  hiss  rvprrssions  thr  i  onipilr-t  i  l  III' 
al^ori'.hm  p.rnei airs  two  t\prs  ol  s\  mholii  I'lpial  ions:  a  “s\  m 
holit  i  lass  i'<|ualion  and  it  **s\  mhohi  llow  ripial  um  A  s\  lu¬ 
ll  o  lie  i  lass  rijiialioii  is  m-rd  to  i.iliidalr  thr  outgoinj;  sri  u r i  1  > 
rhissrs  o|  all  output  \anahh  .  Our  sin  h  ripi.it  ion  is  i  rralril  lor 
rai  Ii  in  1  u. d  p.ir.Hui'trr  in  (  t)  and  ((■)•  regard  Irss  t»l  wlirthri  it  is 
d\ iiainii  all)  oi  stutii  idlv  liomiil.  Tlir  ripi.il ion  haslhrlorm 

vaiiahh*  “s\  mholii  c  lass  expression* 

whiih  slates  lli.it  tin1  inloi  mat  ion  in  "v-uiahlr  has  ii  snuiit) 
il«iss];i\rn  h\  the  “s>luholu  i  lass  rx  pi  rssion  .  A  s\mholii  flow 
nptaliiMi  is  used  in  i  hi’i  k  linvv  \  iol.it  ions.  Onr  si,<  })  I'ljuat  ioii 
is  <  Teat  i'<l  tor  rai  h  statiialh  hound  variahlr  (imludinj^  ohjri  t 
viiriahlrs)  I'lu*  npuition  Inis  thr  form 

variahlr  security  i  lass  •  V’sv  mholu  class  impression** 

vvhiih  states  lh.il  thi'ilassol  "variahlr**  is  statiialh  hound  to 
“security  class**  and  the  inhumation  vvhosr  class  is  f*ivrn  h\ 
“s>  mholii  i  lass  expression*  Hows  in  *’variahlr‘*  dining  thr  ex- 
t'liiiiou.  Moth  1\ ;  m’s  of  s\  mlmln  eipj.it  ions  ,iir  stotrd  Hi  an  ‘'in 
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lormatioti  How  template”  in  l  hr  ohjecl . 

The  distinct  parts  ol  an  inloniMlioti  flow  t <'ii ipl.ii <'  air: 

fcXlMJHT  I  hi'  toie-kls  ol  ni1»i»|i<-  <  lass  rqii.il  ions  lor  tin 
formal  C 1 1 1 T  p.ii.unrlris  o|  tin*  piturduie. 

IMI’OltT  :  I  hi''  <  oiiskts  i»l  s\  mholit  t  l.ms  equat  ions  Un  them 
1 1 1 .1 1  IN  paiamclers  ol  cxteiivl  plot  t*tl  ii  I  *' *s  t  ailed  l»\  ilir 
pint  refine.  Sim  e  thru*  m,n  In*  inoit*  than  on.*  r\(«*i  n.ill\ 
invoked  plot  nliin\  ihk  p«ut  ol  tin-  i-t'it consists  c«| 
a  li  >1  ol  all  sin  h  ptoiethiM*  liana’s.  »»<n  h  ol  uliuh  m  fol 
lowed  b\  equal ion  •  tor  iated  at  t  mil  IN  pat amen  is. 

\\  thr  >«*n»r  pioteduic  is  invoked  liom  N  dillrtrui  plates 
in  the  text,  then  N  distant  procedn  t*s  air  assumed  vim  e 
tin'  samr  plot  rtliiit*  Icoin  diifcieht  plait's  could  taii\  dil 
fort'iil  sot''  i*i  IN  n ar.imolois,  anti  t  onsequeni |\  dillerent 
sot  urilv  <  lassos  t>l  tlio  actual  parameter  \ aim's,  j  1'lir  foi 
matioi!  ol  \  distinct  names  could  sunph  he  <  «ii  t  led  nut  h\ 
a  pirprot  fssoi  piioi  to  compilation.) 

STATIC1  :  lh  is  «  on*  i*  Js  o|  Nxiiihnlit  1 1  < *w  equations  lot  stall 

t  alh  hound  variable-. 

A  sennit)  class  is  not  assoc  i.itotl  with  an  object  itsell  since 
llovs  air  checked  at  tin*  tii.irs  that  its  expotled  ptmoduit’s  art* 
invoked.  Thetelote,  il  an  ohjri  t  is  passed  as  a  parameter  or 
its  itlrntiiin  is  stored  in  .in  ohjri  t  callable.  tin*  toiupilr  t  tint* 
mechanism  dors  not  nrrtl  In  j;rnri,ilr  a  s\  mholit  t  lass  equal  hmi 
<»r  a  j.xmbolir  How  eipialinn  .issik  MtrtI  with  tin*  object.  I- low 
control  is  tallied  out  when  expound  piotetlmrs  <>|  the  object 

......  n  i 

•i«<  t  urn  ii. 

An  "iulorination  How  iiiM.uur”,  hasotl  on  the  intonnat am 
How  template,  is  ri  rated  at  mu  time  lor  rath  plot  rduie  invot  a 
lion.  The  run-t  ime  cert ilic -at ion  met  hauisin  <  oiiqdrtes  the  \eriti- 
ration  work  w  hrn  piocrdurr  in\o(  alitni  1. ikes  pl.it e.  It  i-  done  h> 
replacing  the  set  util)  variables  in  the  inloi  mat  ion  How  instant  t* 
with  act  ual  sennit)  classes  ol  the  t  orrexpoiiditq;  p,itainrit*rs  <  ar 
rietl  !>\  the  message.  II  a  protedurf  I  talk  anot  lirr  pincedure 
in  ainiihei  ohjrt  l,  pan  ol  the  wrilu  ation  <»l  I  ina>  hast*  to  hr 
deferred  until  (i  completes. 

2.  The  ( 'oinpile- Time  Algorithm 

a.  <  tnupile-Titno  Data  Structures.  Iht  pmpo-e  ol 
the  toinpilr-t  mu*  algorithm  is  to  generate  mfoi  nmi  ion  How  w-m 
pi, lies  loi  expelled  pimedures  ami  l he  init  i.i h/al  mn  pmii  dnit's 
ol  ohjrt  Is.  Vi  t  he  outset .  I  he  s\  mholit  t  lass  e\ pi i-  -  n  .u  toi  c  t,  ]\ 
ptojpam  \aiiahle  is  i n it Wi  1  i/t*«  1  a*  lollows: 

I.  I  or  a  stalitallv  hound  vaiiahle  (iik  hitiiu;*  ,i  p.u  .uiirtri ) . 
the  <  lass  expression  is  dr  lined  to  hr  it*-  lived  «.«•*  ■  1 1 1  lv  <  hiss. 

‘J.  hot  a  d>  u, unit  all)  ht>untl  lot.il  v »i r  i « 1 1 » *- *  ot  foinial  (Hl'f 
puiauietri,  tin*  class  expiessioli  is  th'hlit'd  to  he  \l  j,|,. 

•  ».  I*  of  .I  d  \  1 1  <  1 1 1  lit  a  1 1  \  hound  lornitd  IN  pal  .imrtt'i .  the  t  hiss 
expression  is  s\  niholi<  all)  repleseuled  by  t  hr  <  «>i  respond 
iiiH  set  in  it\  \  at  •  s h I* - 

I’  ol  t'fln  it'iit  \  purpose.,  i  etliu  1  ion*.  ,ne  priloimrtl  <n»  rath  s\  m 
hoht  t  la  ss  expiessiuii  in  i»idei  to  %ie|d  a  iMiiiiiii.il  I  *im  Sm  h 
a  minimal  lot  in  iv  «*ilhi*l  \1  I  I  oi  uhmsI  onl\  til  a  fixed  seen 
r  It  \  «  lass  a  lid  /t*n»  ni  nn»ie  set  ill  il  \  v  ar  tables  «  nnue'  1  > *«  1  l»\  "•* 
tiptiafors.  I’ll i re  irdiittioii  rifles  alt'  invoked 


1  Rrpl.u  r  a  s\ mholit  t  hiss  fm  a  lota!  or  output  \ati.ihlr 
in  a  s\  mholit  t  l.iss  r\j*i  fs^in,)  wuh  tin-  class  piessimi 
irpi eseni  nip.  I  In  t  lass  «>|  1  hr  v.it  iah|r. 

.  Ih'ltie  all  duplit  ate  "ct  in  |t\  \ ,u  i.i hit**.-.  I m  example, 
a  • ;  h  *.  a  a  «;  h. 

|  )eleli*  ,i  1 1  xrtl  s»*i  n  i  il )  c  l.iw  il  ,c  h iph*  l  <>f  rt j i i.d  *  lass  i*\ist s 
in  1  hr  rxpicssioii  f-oi  example. 

M  Id,  !  a  a 

l  ow  men  i.nw  men 

mar  i;r  toi’si.um/i  torm-.cim/i' 

lie*  ftdlow  nij;  example  i  llust  j  .it  e.s  tin*  irdmlion  to  minimal 
loi  in  fin  two  sm  t  t*ssj  \  ,■  assignment  st  a  lenient  s; 

statement  s\  mholit  t  hiss  etjn.it  i«»M 

t  a  •  b  a  t  a  h  •  ,i 

a  w  h 

d  :  ,i  t  <i  a  t 

a  >  a  ■  li 

a  •  h 

I  he  algorithm  irtpjiirs  two  .-pet  ial  i  tun  jule- 1  ime  vaii.ddt's: 
a  st  ,;t  k  «>  pe  \.n  i.diie  S T  \(  l\  ami  a  s*;nple  \.o  i.dile  <  .h<  Ml  \1, 
S|  \(  lx  t  tuil.uns  the  st  t  in  it)  classes  ol  the  expressions  on  w  hit  h 
the  statement  (tmenih  In  in-;  an.d>  /etl  i-  <  <mi<1i1  iou«*d  Thus. 

\(  lx  ai  t  i  a  in  I  s  (iii  implicit  i  |o\\  s  ( 1 1  >t  a  I  I  low  s.  mi  \  n  d  i  t*w  and 
Redmans  model)  \s  in  I  )rn  ninp,  iu»*.  al  ion .  ST\(’I\  tit'iuiles 
1  he  t  lass  on  I  In*  I  up  n|  s  |  \(  1\  ant!  the  |  \(  ‘  |\  piish(e)”  op 
t*l  at  loll  adds 

MMh  e 

1 1>  t  lit*  t  op  o|  S  J  \(  |\  I  lie  “SI  \  (  |\  pop  opei  a  I  toll  i  ei  im\  rs  1  he 
t  lass  on  i  he  lop  ol  >>  I  \(  l\  ( .  I.(  )H  \  I .  holt)',  a  t  hiss  ol  t  olid  it  tonal 
expressions  n>  rt'Het  l 

1  i  1 1 1  ] » 1 1  <  it  tltivvs  wlnth  will  he  in  ellet  !  altei  t  oinplel  ion  til 
execuiion  ol  “w  lulr  st ateineiits  in  the  same  manner  as 
Amhew  ami  |it*|i  man  s  global,  and 

'J.  the  impluil  inlet  ohjrt  I  How  v\  kit  h  will  he  (low  iii)>  Imm  .i 

tallei  t»l  a  plotvduie  |R()t*  lu*u,j;  t  t‘l  t  ifird 

(this  in i pi u  it  mlei  oh|t*t  i  How  is  denoted  h\  setuiilv  \aii 

able  I  ROi’.nnpln  it  and  i  •  explained  in  subset  1  ion  ()  >  c  ) 

t  he  t  las*,  contained  m  ( ,  1.0 If  \  l-  is  th  now-d  l»\  1  d.(  )li  V  I.  ami  is 
initiaii/t'd  to  I’ROC  iiiiplu  il 

l  lit*  at^oi  it  h in  ako  uses  t  om pih  lime  a 1 1  .<\  \ai  i,ih|«  ^  s(  *  ,, nd 
I  \  I  *  It*  I  ol  1 1 1  s  \  n  1 1  m|  u  etjU.it  it  ill**  I  hr  don  ia  in  ol  v  (  ’  is  thr  s(*|  c»| 
■ill  I  hr  \  ai  mbit's  w  hit  h  ale  iisi  d  m  a  \  n  >  d-i i «  I m  i ..a  c  t  1 1  il u  d 

I  lie  d  ‘  '111, i  ill  ol  I  Nl*  miWhls  t  *1  all  1  Sit  w1uli«o|l\  ln«und  \.iti 

aides  lea  d  in  iht  p  1 1  h  i‘d  1 1 1 1  - .  |,u  a  «i\ n.inm  ,ill\  Inamd  \aiuddc 
\-  v ^  X  is  I  ht*  s\  iiihcd it  t  las-  e\  pi  e  sKl.,  Jm  ^  |  |M-  .d^oi  U  | ■  * i  i 

t  oiis|  i  in  |s  j  he  s\  1 1 1| >i,|i(  i  |,|ss  »  «pial  it»M 

X  X 

II  \  W  a  lol  leal  (  )l  1  T  p.u  a  UMlel  til  l  hr  pi  t  It  i  du  I  r  hi- -|||«*  t  oil  ip  lift! . 
I  he  etpi.l1  It  >11  is  pl.it  rd  ill  1  hr  I  A  l‘(  >  R  T  t  .ilepn  v  1 1  \  man  .u  l  ual 


ry) 


IN  |*iii  .mu-1  el  u|  ,i  pi  (ii  n!i mi*  to  !*i  invoked  in  .im»l  hei  ohjn  \ .  1  Ik* 
t  mu  i-  pi. uni  in  the  IMl'Oli  T  i.ilrj’iitv  nl  1 1 1 «-  ihlm  mat  mil 
HoW  template  li  ,i  \  it  r  i«i  1  »)i*  is  Sl,l1li.l||\  hound.  V'C  \  «  «.i  1 1 1  «i  1 1  T'~ 
ils  Ii\ed  si  *i  ill  1 1  \  i  1.|n*n  and  1 .  \  |  *  \  idiiI. ini*-  « lie  i  hi  i  cNjimnliiiM 

N\  Mil  •‘•III  I  1.1*'*'  r\|lll  ^loll  I  In-  .1  I'M  >]  ll  lllll  l  mill  1 1  ill**'  l  1 1  !■*'(*  I  WO  lo 

t  un^t  i  lit  t  I  In'  mholu  I  low  expiation 

\  M‘\  •  I  XT  \ 

.uni  phu  es  it  in  lilt’  S|  VIIC  i;iIi*j;m\  ol  llu*  iiiiorin.it  i«mi  I  mu 

I  cm'  1'1‘iti'. 

I  lir  ti>Mi|»il“  linn*  nlp.oi  il  inn  is  j;i\n*  in  the  Appendix.  Suh 
M'lpn  tit  sii  1»m*i  l  inn*-  diM  iins  m»|iii*  spec  iit I  Neman! it  details. 

Is  Informal  ion  Flow  Srin.intirv  of  Am i^nuient .  \s 

siiim'  iiu  iis:nj»n?nel.1  sl.iteii .cut  ol  l  tie  j»enei.d  Un  in 

x  :  !pi| . <»,.,)• 

II  v  is  <1  d\ n.niiii  ,ili\  Imimd  \ariahie.  the  Jilj^ol  itlim  j;rlirt  .it t*s 

Sl’\  Si  *  c,  i  1  :  M*  nMfl  •;  -STACK  i  Cl.OliAl.. 

II  x  is  it  st.il  it  all\  hound  \«n  i.it>li\  t  In*  .ili\o!  it  tun  upd. tit's  h\r  \ 

ll  n 

l  AI*  \  lAI'v  si  ii i  •  •  •  •  :  SC  ,I„.  •  sTA<  K 

■  Cl.OhVl 

Tilt-  lolloW  ill**  e\.llil|.le  explains  w  li\  Updatm*',  (instead  ol  ir 
pin*  iiij*)  <it  i  l. inn  i‘\ pi  e*  n'huin  i*.  iieii“-.M\  loi  •-l.ili.ilh  ImmuuI 
v  .■  i  i.dile*s.  s%'!i»pivi'  \  i-  ,i  -I, il’n. ill\  Imtiini  \;n  i<il‘le  .nid  iiiiliallv 
s<  \  t  w  N  i-  i I » i . X  i  i  \  i  .nui  i-.\l*  \  \l  !.S. 
tin'll!  s  si»||s  the  Value  o|  v.-.ii.ilde  \  to  \  and.  Kilt  i  Hi  the 
1«  xl  .  s(  .i  t  el  miit  ,r-N!jpe-  t|u  v.dm*  ol  N  to  A  I  Ml,*;  simple  ie 
p!«u  i  1 1  ■(- 1 1 1  .  I  lie  -\  tulndn  t  Lrs  t Apn  s^min  j;i  mi  .it  nl  lot  x  .md 
>,  We,: id  hi* 

I  \l’  \  X  M\C|\  Cl  OHM  .  .md 

h\l*  \  >l  STU’K  :  CLOU \h.  i("-pe.  Iivrlv. 

II  si  \(  l\  ChOlt  \|.  is  I’UOC. implicit  loi  luitli  .md  SJ 
.md  tiieic  .Me  no  othei  Ntoienieiits  tli.il  «i**sij;:i  value*-  to  A  allei 
.  t  lie  llow  t  ip:. it  ion 

\  COM  U>I  A  I  |  \1.  Y  LOW  I* IUH ‘.implu  it 

would  he  i  oiini  i  in  t  imI  olid  pi. lied  in  llu  >T  \T|C  talej’.oiv  ol 
lilt  tempi. itr  Assume.  .it  mil  time,  the  1  I.inm-n  ol  \  A  .md 
l  h<  unpin  it  inlei  ol  >jet  i  Ih.w  ,ne  v|Cli|  !.  C()\|  IPI  \Tl\L 
o  ml  I .(  )  W  .  l  espi  \  1 1\  el\  (in*  i  u  ii  1 1 me  t  <- 1 1  itti  at  ioll  alj^oi  it  Inn 
\>  i  »u  Id  i  ep  ini  e  \  *md  I '  |»  Ol  1 1  n  j  *1  u  it  in  llu-  ^  v  mho) u  ll.  »\\  ec  pm 
t  i‘  ’ii  loi  \  "  it  Ii  l  OM'  IDIA  I  l  M.  oil  d  I .( )  W  .  l  i*Npei  1 1\  cl\  .md 
would  lefliiv  the  llow  |*.\  i*n  1 1 1 « >n  *avli  \  IioIiIn  COX  HIM*  A  II  \|, 

i  n  1"!  1 1 1 , 1 1  ion  .it  llu  end  ol  llu  exeiutioii.  i  lu*  pi  op  i. mi  violates 
t  li<’  How  poll.  \  h\  Ntu: n|-  ( ■  p  |  |  ttiloiii  i  .i  I  ion  (t  l.ms  id  \ )  in 
\<iliii|ile  \  dm  n  If,  the  lime  peiiod  1'ilweni  the  e\ei  ill  o|  >, 
.md  v  I  lieii-hne.  ii|Nl(  ,id  ol  i  epl.it  ei nelil .  t  hi*  i  hiss  e\j»i  eNsioiis 
loi  xi  k  ,ill\  hound  \  <u  in  hies  iii:in|  |>e  .u  .  imiiil.il ed  le-inj!,  t  he  •  •  • 
oprt.itoi  Ml  iu  del  In  .it  (  mini  loi  •*  1 1  po^Nilde  iulm  in.il  imi  Ho\\n 
I  he  till  it’ll  s)  uiliolii  lieu  e«ph.tion  loi  \  in  I  lie  ,ilu*\  e  ev.iiuple 

i- 

\  COM  IDI  ATI \|  ■  \  ^  |.()\\  :  NiOC  iinpliut 

i.  I  iiloriii.it  ioii  Flow  >i(*tii.'int  it's  nl  l  ondit  iuiial.  I  ni 
v‘l  h*t  i  ioii  st  .lien  u*nl  n.  l  |u-  imnpde  lime  .il^niillmi  ,k  munis  loi 
1  hi  |io.-ll>i!i|\  ot  e\eitjiiiij;  eilliel  .ill  (|  n.il  n  e.  foi  ex.iii'ple.  in 


I  lu  O  .it  ement 

if  .\  (!  t  lien  \  :  h  x*iNe  \  t  . 

I  lie  .i|j;ni  it  I  Mil  i  nie-1 1  ijt  S  the  ^  \  ml  ">ht  i  he  *-  «  \;»li  *--i«m  h 

(  .i  .  in  i » Mm •  nip,  h u  t  he  un  pie  1 1  llow  1 1  oin  “,i  .mm  I  t  lie  e\  pin  d 
Mown  tmni  ho’h  ”h  ..lid  i  ll  n  jiioiiihue  i.ill  to  enoiiui 
ol»|ei  t  "Pi  e  (oiiditumed  upon  -,'iur  \  ,i  i  i,ihle(-- ).  then  tiuie  in 
.ill  "i  I  n  p  1  it  it  inlet  ohjei  t"  inh'i  in.il  iun  llow.  J  ol  eN.iinple.  in  the 
st  .it  elneiit 

if  .i  t!  1  lion  h  U  l  l( \  ). 

lliele  is  ,i  |’o\\  1 1 v >i n  "a  to  tin'  lot  ,\1  i.iimMin  and  ohje.  I  vat  i 
.lhli’N  «*iM  apsiilated  l»\  IM  (.md  iihjeits  tailed  h)  pioieduii'N  ii 
It  Cell.).  Sun  e  ililoi  ni.it  ion  lh»\\  ^  .11  fn:w  oh  je»  t  hoil  lid.i  I  ies  ,i  ie 

i  ei  I  diet  l  at  mu  !  line,  spet  hi]  1 1  ea  1 1 1  .eiit  ol  t  liesi*  nil  pi  u  ii  llo'\  n  is 
letjuiied. 

\  o  ha  lu  lie  1  Ins  imp]  u  d  llow  .  I  lie  i  oinpile  1  nne  al^oi  ithin  <  on 
*-l  i  nt  p-  ,i  n j »(•(  |,| I  n\  1 1 d >o|  u  i  la*'*'  c\  pi  <'Nvion  .  deiiot ed  h\  n 1 1  pin  1 1 . 
v\  im  h  ivpiest  1 1 1 n  i  he  .ii  i  limn  la  1  u 'ti  ol  i  la  -'-es  on  im  h  l  lie  me. 

«  c  «lme  in\o(  at  mu  r  1 1  unlit  min'd  linpli.  il  in  at  In  ,  ilv  llu  i  I,.nv. 
ol  oal‘*,»>iiie  1 1 1 1 1 1 1 1 \  it  nitei  ohji'i  1  lh»v\  ami  ii  n.is  :ln*  hum 

>\  |  .  S  l  ,  PPt  '.iuijihi  a 

wheie  S\,  denotfN  llu-  illi  \ .  1 1  i ,  i  hit-  on  w  )m  h  the  imoi.itiou  is 
lo*  all\  t  ned il  imied  and  I’KOC  in.pl  n  il  delude*  l  In-  t  las*,  lot  I  he 

ii  a  phi  it  :  nl  ei  ohjei  t  llow  imoniMi^topioiediMePKOCtioinllie 
pie\  lolls  (  allinp  oiijei  \  .  Impht  it  isstoied  \\  il  Ii  l  lie  i  ol  lespond 
i«i>;  pi  oi  ed  u  i  e  ii  one  in  the  IMIOU’I  t.ile^ofN  oi  the  teinpl.it  e. 
(I  h  1 1  n  .  ,»n  ('nl  r  \  in  tin  lemph.  t  e  h»i  e.u  h  ev  1  ei  n.il  pi  ot  i*d  in  e  has 
.i  *-\  nihniu  i  lasN  eipi.tl  ion  loi  implu  it  as  \.i  11  a  a  tali  dll  t  l.e.s 
eijii.ition  Im  e.u  h  n|  its  ailnal  IN  p.n  .mieteis  )  \i  mil  tune, 
a  leijiiest  Ini  a  piiuediMe  in\ i  m  at  loll  «  .mses  the  inn  lime  ai|;o 

I  it  h  ii.  to  e\alu.lte  the  t  oi  uspniul  i  ii|*  nil  pin  it  as  l  ae  »  l.»ss  ol  the 
oul^oinj;  implu  it  Mow  Tin*.  \a!ui\  as  well  as  lli  *  ms  hi  i  t  \  <  hiss 
ol  eat  ll  p.i  i  .ii net  er  .  is  at  t  ,it  lied  to  I  lie  mrw.ij:r.  I  poll  i  e»  eipl  el  a 
iuev.,11'1*  |i\  a  t  e<  ei\ ine  ohjei  1  I  •  !  loi  l  lie  pi  «u  edu  I  e  i  all  U’lpiesi 
I .  an  inh'i  * n.it  ion  How  iii’l.iiu  e  is  t  iea  1t*d  .md  1  he  set  unt  \  i  la  'S 
in  the  inesMi;,’  loi  the  iiopli*  it  inlei  uliji  i  !  llow  (now  di  notes  in 

»  ol  lli  M}’,  1  III  pi  I(  ■  t  tlo\«  )  t  epl.u  I*N  N<-|  U  l  It  \  \  .  1 1  1 . 1  I  >  I «  |  1 1  liplit  it  Ml  v  \  111- 

l't»!n  i  hiNN  e\ pi  e-  Niolis  in  the  inloi  in.il  ion  th*w  m-i.iiu  r  Suin' 
implu  it  ol  e.u  Ii  p! « u  **d  U 1  e  t  li  1 1  \  >  1 1  the  I  \  |  I  ’OK  I  •  .iU  jpa  \  mil 
tains  l.nnjiluit.  suJi-r«jmm  pio»e<!u:i  in\o,.iiion  i«‘pii*‘t*-  lo'in 
tills, d>|eil  In  \  et  Ollul  ohjei  t  -  t.ilix  .ill  ,u  «  iiiiml.ilnl  i  l.ms  ,»1 
t  he  implu  it  Mow  m  implu  n 

1 1 1 1 1 1  lu.  1 1  th'W  s  ,u  j  ,»*  s  oh  |«‘i  1  I  hum  >1  Lit  It's  ot  t  III  even  wilt’ll  p!  o 

I I  dm  e  in  v  i  u  a  I  ions  .Me  st.  ipped  I  .ohi  i  e  to  dm  k  loi  nih  Ii  in  i 

pht  it  Mow  v  i  ,mi  load  t  »>  u  iu|(  1 1 «  ! *  d  •••,*,  u  i  it  \  \  u>*.i  t  ion  I  h  is  c  ,\  u 

lie  t  leaf  l\  1 1  111  si  l  .ited  ill  .i  p: .  >j.i  .mi  wilh  d\  I). linn  .dl>  lit  mild  oh 
Jett  \  .i  i  i.i  Ides .  llu*  ex.impL*  ploei.Mii  in  I  ijoae  t  e  adapted 
1 1 1 1 1 1 1  'Z  ■  \’-*imie  lh.il  « t  <  1 1 1 . 1 1  IN  paiametei  \  lo  pioi  .■.hi..- 
|i  1*-  Im  ui  ml  lo  sl.l|{  I'  I  .Mid  lakes  a  value  eitlui  otu  » ■  i  /t'U*. 

d\  n.iinu  ,dl\  I'oinul  ioi  in  ..i  oi  >T  pal  a o u*1  <  i  \  ol  h  i-  mil  i.dl  v 

hound  to  1  \  C  I  \  v''s  |  |  I  I-  I  >.  .1  nd  *  1  \  n.il  i  in  <1 1 1\  1 1,11)1  II !  ,  i|  1  j,’<  '  \  a  I  i 

.  i  h  | .  /  iii  I*  .imi  \\  iii  ( !  .Me  lint  M  i|\  In  Mind  lo  t  Xt  I.  \  's,s||  |{  J) 

I  ll  n|  .  .I-VIIIII,  \  1 ,1  |X,-N  \  .line-  till-  one  >l  ill  e  1  he  Mis  m  a  1  loll  K  I  \  )  is 
-  1  t  p|  m  ,  |  1 1  \  ,d  m  .md  1  lie  i  |.isn  ol  /  n:  K  i  eii  i.i  1 1 1  /i  i  o  ,i  I  nl  1  X 

t  I  \  I  I  II  I  >  I  lie  1  ll  \  oi  .i  1  loll  K  j1,  (Ol  'T  ,i)  1 1 1 hi i  1 1  ui  in  ii'<  1 1  in 

.  i  nil  l  \l  |  V'n"  1 1  ||  I)  loi  a  !  lu  leioie.  t.^.k()  i-  invoked  ami  W 
in  he.  on  if  -  one  ■  t  1 1  •  I  l  X  C  i .  \Ss  1 1  1 1 .1 )  Then  l)  iu(OC'r  >) 
!■!  ui  ll-  ol  ie  a  lid  \  NCI  \  'ss  |-  J  |-  1 )  |oi  \  Now  .emiin  llir  v.iiue  cl 
\  i-  /,  i  o  S||14 1  K  I  (  )  is  inv  okc*d  .  I  lu*  v  aim*  and  l  he  t  he  ^  ol  /.  in 


(*0 


ibji'ct  r 

<d)jert  |{ 

ohjei  t  Q 

liroccdiirc  li  ;  1 M  \:inii^«  r. 

state 

si  ate 

Ol  'T  >  . i ii i . -j;.  i  ! 

/  inregi  r  ■ 

W  ilMege 

procedure  If ) 

procedure 

\;ir  .1  :  fmolc.iii. 

l».‘”  in 

l«-hiii 

\  :  II: 

/  1 

W  :  1: 

if  x  0  tin'll  U .1  ( ) 

end 

<•11.1: 

It  r((  >1  T  .i): 

pi  rn  ednre  «» ( .U  'K  \  :  Im»o1* 

]ir<K«‘ilur< 

if  .1  thfii  Q.k(): 

hegiu 

l»'j;iii 

Q.ni(<M IT  \  ): 

if  /  (I  1  hell  \  :  1  rue 

x  :  W  : 

else  \  :  l.i  he; 

i’ll.) 

[■lid  1’; 

end. 

inil  i.i li/c 

init  i;ili/.e 

l)«*Kili 

begirt 

\\  .  0. 

/.  :  0: 

.■i.il. 

end ; 

.•in!  Q 

end  If. 

f  igure  1.  Iruphi  it  1  lows  \(  u»ss  ()hpi 

1  1  1  tlHIl  |  •  |  .1 1  i<"- 

li  hei  t 1 1 1 1«  -  olir  .Ulil  x  |  .<  If  I'/l  .  I  Jills.  I  Ii«-  Hi  V  <>(  «il  ID  1 1  If  g(  (  )l  T  it) 

( <  1 1 1 1 1 1 *>  I <i l"i  <1  it' I  sd .<  ‘ If I .  I  lot  •>.  Sin<  k[  j  is  -ki|i;n*i| .  \\  in 
remains  vent  a  lie!  I  \<  I.  IK  I).  'I’  Si«-r  t*lc*r  <*.  (|.m(0|IT  > ) 

ri  lufih  /rr<i  iunl  l  \(  ’I.  \ S>||-  IKI>  lor  \.  Note  I  flat  alter  t  \ec  II 
t  ion  ol  li.  \  li<<  onus  «*<| (let I  1  o \.  However.  \  errotiemis|\  remains 

l  Nv  i,.\s-di  iKi*. 

I  n  our  model,  flu-  errors  dest  rihed  in  the  pre\  ions  paragraph 
(an  In*  |»r  ev rnlctl  >iii<  <  itll  tin-  i»|»jcc  !  variables  arc  static  ullv 
bound  to  scuiritv  c  las'* i  s.  However.  when  |if(H  edu l <*s  ale  in¬ 
voked.  i  lx*  rule  t  line  .i  lg««r il  Inn  mi, si  pi  rforin  I  lie  follow  ing  w  In  n 
an  ihionnal ion  How  violation  h  driei  ted: 

I.  The  \  i< it«>  1  i n *4  prmed.ire  m\ «*<  at  ion  e  skipped 

2  l  |m  e\(<iilioti  (  oiil  1 1 :  i  •  i  *■  .e  li  no  tlow  V'oLtliOli  win  dr 
l<  <  led.  .uni 

.*'»  Iln  How  «  imI.i'ihii  i-  to •:  n  | ii ■  1 1 «  d  !o  i  la  i)s<  r  In  tin  w.i\. 

tin  1|S|  r  I  Iihluil  I  In  III  i  III  1  wee  1 1  ,i  -kipped  iIii'K  «i  I  ion  till'd 
oil  I  li.il  l  ill  \  iol.il  li  ill. 

.“siijipn-e  lii.it  in  tin  aliov*  i\.iin{de.  /  in  o!ip  *  1  If  «»nd  W  in 
uli|i*i  r  .i  re  •«:  it  a  all  v  I  uni  ml  to  t  lt.  I  .i  )\\  |  lien.  I  lie  >  I  \  I  I* 

i  iilegor  irs  ol  1  Ik  ilil(>r  nitil  Mill  How  t  eli i pl.it  <  s  |m  if  |( )  «iiid  (_2  k( ) 
have  tin  s\  nil)o!i<  ||ow  i-(|iia1  ions 

/  |()\\  ■  |,()\\  I  1 1 1 1 1 1 1 1«  it  .  alld 

\\  1.0  \\  l,()\\  k  implu  1 1 .  ie-'pi  i  livelv 

lil  .  Ii.iv  «  i  Los  1 1 1(  1 1  an 1 1  v  a  I  ■!•  i  an  .  a  In!  I<1  V  have  (  l.e  *  I  OW 
I  hiii.  If  l[J  r-  not  (ailed.  and  I  lie  invalid  I  low  ol  \  :•  /  i  imi 

drill  lei]  I  I:  i|s .  |f  gfOl’T  a)  irlMflls  1 1 1|<  and  I  <>W  loi  ,i  .Un! 

(^k()  is  invoked  with  neplu  it  |,OW  no  How  vml.ii'nii 

|s  ih’li  (  li  •]  when  Q  k  (  )  |s  ill  M  »k«  d .  W  III  ohji-t  i  hi  (  linn*-  mi* 

•i ml  •  oii  -eijm  lit  l  \ .  Q  id((  )l  T  \ )  ret  ur  ns  one  in  \  II  \  Ims  \  .dm 
om*.  t  In  n  I  f .  I  ( j  i -  invoked  willi  miplii  it  IIH-H  I  In-  in\«»  ,i 
t  ion  <  ansi  s  a  How  v  mlalion  I  lie  invot  at  nai  to  if  l(}  is  skipped, 
tail  the  e\«(iilion  lonlMnns  w  il  l.«»,r  repotting  tin  v  iol.il  mn  l.t 
the  i|si*i  ,\s  a  resiih  .  /  in  ff  [i  n  lain  s  /i  i#»  ,oid  i.( )  W  .  and  <  on 

Seqin  lilU.  \  Il  ls  Value  om  .  I  In  Irlau*.  the  Value  «>!  \  <  ali|n>l  In 

t|e(hn  ed  (loin  t  he  v,|Iim  ol  \  lngiiler.il.  I  eiilon  proves  that  if 


all  v  an.dde  '  a  re  st  a  •  a  ll\  hound  sriuiMi  t  all  he  gu.tr«iulred  h\ 
v  ei  il  v  mg  old  \  lii iv\  s  i  a u  'i  c I  h\  e\ei  ijl  ion  o|  «  \  idu  it  assignments 
I  low  e\  el .  the  ru|i-1iine  algorithm  nii|st  do  l  In  following  when  a 
flow  v  iol.il  ion  is  dele*  led  7 

!  T!..  i-  sk,|.iH.| 

2.  I  .\«i  ul  ion  i  oni  nines  as  il  no  how  violation  were  del  et  led. 

I  he  How  violation  is  not  reported  io  the  user. 

d.  luforiiiat  ion  Flow  Semantics  ol  Iteration.  hem 
l  i v  e  <  oils  1 1  in  t  -  a l-o  re<pni  e  s p,  i,i  |  <  oie id<  r  -it  jori .  <  oiealci  t  lie 

t  xaieph 

a  \ : 

will  It*  .1  (.’do 

lil  1 1  : 1 N  ..  Ol'T  lil: 

li.1  lil  IN  li.  Ol'T  ii ). 

<’>nl . 

I  lie  il  r  sj  l  1 1 1 II'  tile  boi|  V  o|  the  loop  1-  e\i*i  i|  I  ed  .  1  he  -<  i  u  1  I*  \ 

(  |,iss  o|  ,«c  1 1 ;  a  I  IN  par  a  meter  "a  loi  If  I  f  I  is  \  1 1<  iWi  \»  |  .  Ml 

S||  1|S|  ( 1 1 1  ( -  y .  i  1 1  (  I  at  |(  III I  lie  <  l.e-  *>l  "-i  I-  the  *-ri  'll  il  \  i  l.e-  « *1 

I  II*  Ol'T  |  • « 1 1  aim  Ol  \  .i  1  ■  i  <  I  r  mi  ■  |f  J  |  J  di  1  r  i  mined  in  1 1n  pit  v  i 

o* j s  1 1 1  I  a  1  lot  i  's  i  ’ii  *  tin  !•  i:  |  ii  I  h  |  i »!  I  1 1  m  -  I  la  It  •»  »J »  In  >d  v  \\  1 1 1  !  m 

*  \*  *  lit*  *1  is  imk  now  n  a  1  i  on  ip  ih  l  i 1  oi  .  i  l.«  i  i  ai.pih  a  n  i  a  i  ■*  i  I  .■ 

II  |s||  I  1 1  M|s  I  pr  ;  W  l*l<  h  if  \l  lllil  illiOH  oi  V.oJ'!  (  ,M  1 1 1  f «  >1  Mi.lt  N  ill  Hi  »\\ 

|  Ills  I  I  .p|  |  T  I  S  I  }n  S  eiltl  l.t  t  Mill  of  11  I  I  ,|l  U  *I|S  II  I  I  I  I  1  1  III  s\  |]  ,  hi  if  II  *  !<|SS 
<  \  j»M  ss  |i  ue  s |  ,|t h|  i/i 

W  |1  h*  III!  s  |  It  -*  |,t  |  j  It  ,  1-n  H|S.  I  !|*  SV  1 1  I  hi  I1  h  1  la  -  -  «  Ij  •  i  .i  I  ii  mi  h  1 1 

"a  Would  he 

.1  X  ;  If  M2.! 

a  ml  t!n  r  ii  nt  Mn  e  iim  <  h  auisrn  would  sj  mi  j  il  v  i  rpiai  e  If  2  i .!  a  with 
I  in  i  l.e  s  i  )|  t  hi  (  )  I  T  pa  r  .ill  i*  1*  T  v  ,d  >M  w  1 1 » -  r  i  t  In  ohj*  *  1  im  nr  ,i 
o  torn  tin  -  sagi  !  I  out  1  lie  hr  s  t  inv  m  al  ion  of  ff  2  12  I  hit  I  h  i  w  « n.ld 

hi  iim  dMk  1  si!n  i  tin  sci  i|  r  1 1  \  v  a  r  l.d  dr  If  .M  2  a  w  t  mi  h!  l  I  ii  ii  d  >s  a  p 

C  i 


pear  iruiti  l  lie-  -\ iiiImiIk  *  las-  equal  hui  fur  ".i  am)  i he  <  <ju.il  inn 
would  mil  1 1* 1 1 1 -<  1  tin*  ailuai  iiilnriiuil  ion  lh»v\s  fjnm  suhsequim 
ih\ o<  (i  1  ions  <>l  Ul?. 12.  In  order  to  coiiecllv  «t< <  oiint  lot  flows 
Iroin  p  roe  •  *f  1  if  t  <*  <  alls  ae  ross  .ill  iterations.  the  |  iin-1  line-  inn  ha- 
rii-in  tmivt  add  tin-  classes  (»|  i  Ik-  ret  iiiii  values  to  ilii*  s\  inholie 

<  lass  expresMcui  instead  of  repla*  i  nj*  the*  ‘.remits  variables  In 
orde'r  t « >  ielcntifv  thr  procedures  invoked  within  loop'-,  till-  coin 
pile'  1  i 1 1 1<*  Hire  haiijsin  ii1l<K 'In’s  <t  r i  accumulation  flag  (dc-lioted  bv 
(■))  l(>  III.  see  uritv  variables  for  sm  h  |ir« >c  iilurrs.  Thus,  ihc 
sv  rnbolie  class  equation  for  **a"  in  ilie  *ilio\r  example*  is 

a  x  If  2. 12. a  (  ■ ). 

3.  Tin*  Rim-Time  Algorithm 

]  lo-  i ii :i-i iim*  .dentil Inn  ts  iuvokt-c)  w  In  m  ve  r  an  ol»jc » i  m  ii<K  or 
fi  i  r  ives  a  me*  \h  s  age-s  vv  h  :<  h  a  1 1  n-e  eiveel  bv  <>n  olijv  •  1  () 

a  l  e: 

1  re'epiests  to  invoke  pi  <»(  e*i|u  re*'*  whuh  .in-  exported  bv  () 
a  ini 

2  relurn  message's  from  r hr  <  xlcr n.il  proc eelurcs  invoked  bv 

(> 

Messages  \\  Iim  h  .ire  sen!  i»\  an  object  O  iirc; 

1.  reijuesl v  to  invoke  external  pro<*adiiic  in  another  nhjee  t 
and 

2.  return  messages  Imm  exporled  pioc  <  ■  in  i «  s  whuh  In  mi 
Mate  in  (). 

W  hm  ohjee  t  <)  receives  a  request  to  invoke  ail  e'Xpoiled  pin 
cedtire  l'lfO(  .  tin*  run-lime  algorithm  <  mile-  an  mlnr  mat  uni 
flow  instatue,  which  is  ,i  topv  oi  the  inlor  mat  ion  How  tempi. Me 
for  l,|{()(\  and  repine  <  s  security  variables  lor  1  he*  inleT-obje-e  t 
flow  and  fill  formal  IN  parameters  \v  it h  1  lie  *  orrcspoinlmg  ae  - 
tnal  see  aril v  classes  carriee)  bv  the  message.  Note*  that  il  the 
mi  urity  variable  is  marked  with  ( ■ ).  the*  nlgoi it !im  adds  the  ac  - 
1  ual  see  uritv  <  Les  lo  the*  t  lass  expression  e  oiilaiiiiug  1  he  s«*<  unlv 
variable  (rather  lli.m  replacing  il).  The  algorithm  then  e  kec  ks 
h>r  a  Hem  violation  in  each  How  equation  in  the  Sl  \  I  |C  cate 
gorv.  If  all  t  he  eeju.it  ions  are  c <*rt  ilird  to  be  see  me.  the  jeipirst 
is  accepted  and  a  new  process  for  {’HOC  is  initiated. 

H  |*K()<  ’  invokes  an  external  procedure,  sa\  “<)  J  .lime  !*  .  e*x- 
ee  nl ion  oi  |’lt(H!  is  suspended,  The  mu  time  algorithm  the  n 
looks  tip  the*  eii  I  r\  corresponding  to  Ol.ium  I  in  the  IMIM)HT 
eat  egon  of  t  he*  in  lor  mat  ion  How  itisl  am  <*  and  plae  es  t  lie  se-e  urity 
c  hisses  ol  t  im  c  or  responding  acl  ual  IN  parameters  and  implicit 
in  t  lie1  < >1]  1  going  message. 

In  <;e|ie*r  al.  1  he-  *.\ rnindie  e  lass  cepi.il  ieui  in  the-  inhiriii.it  ion 
How  iiM  aiu  r  e  ni  le-pnndmg  to  pal  anr  let  \  < >f  ( ) !  him  I  has  ; he 
i«  n  im 

x  >  f  i  s  \  M  ■ 

when-  >  \  (|  ti  m)  sf  amis  |oi  the  i  i  h  ^e-e  uritv  v.iriahle  and 

>  (  "  si  in!-,  i<  a  ,i  fi  \i-i|  sn  ii  t  n  \  c  lass,  f  h«  m-i  iii  i1\  \  a  I  i.i  h  le**  a  re 
i«;i;oreel  s|lM  j  1 1|«  \  di-nnl e  1  he  s<-<  m  It  V  e  he  '•P'  ed  v.n  iables  w  h  it  h. 
.M  1 1 1  is  pe  a  lit .  .lie-  licit  \  <1  flow  :ng  nil  o  \ .  I  lie)  c|<  Me.  1  h «'  alj;e»i  M  Inn 
mil)  uses  S(  *  to  i let i  mime  t  |i«-  se-e  uritv  i  lass  ol  ae  t  ual  parameter 
X  I  he-  .iss|m  miieiits  lo  s  | r < > 1 1 1  lh»-  input  \«n i. tides  <  or  re  -pond mj; 
to  I  he  se-e  UtllV  V  a  1 1. tide's  tli.iV  n(  (  lit  lal.  l  (ill  the  ease-  ed  loops! 


or  lh»-\  have  «*lreae|\  been  skipped  ami  will  m-ver  o<«ur  in  tliis 
par  1  ie  ular  ni  ieui  (it;  t  lie4  e  ase  of  il  star*  imnis  or  alreaeJv  ter 
Ii  ii na tee}  loops). 

\\  lie'll  oiqee  l  O  ree cives  a  ret  ill  n  n:ess.,^(  Imm  another  (pie 
\  ieujs|\  inv  oked )  onjet  I .  the  alj;orit  Inn  r  e-pl.u  es  (in  l  }i«  •  inhu  uia- 
t  ion  lie i\\  ilisl  a  lie  e)  ev  t  r\  oce  u  rrene  e  eif  t  he-  si-  ij  r  il  \  \  ar  iahh's  feu 
the  aetu.il  Ol^T  parameters  with  the-  e  oi  re-speindm*;  MomU 
(lasses  e  arrie-d  bv  1  he*  message.  I  he'll  it  e  lire  k^  lor  (low  viola 
t  inns  in  ea<  h  sv  ml»oh<  How  equal  ion  in  1  he*  >1  V  I  K '  e  ale]»or  v .  1 1 
no  llovv  violation  is  deMedeul.  the  messaj;e‘  is  accepted  and  the- 
(suspetiele-el )  Calling;  proles'-  ;s  resiitneel. 

f  pon  normal  termination  of  I’UOC.  l  lie-  n  l^oi  it  h  in  looks  up 
1  he-  lAI’OIH  eatej.'or\  of  the  inlormaliou  flow  insiameand  al¬ 
ia*  lies  the  see  uritv  classes  to  the-  •  orre-spoml  mg  lornial  ()('T 
pa  raiiie-lers.  .\lle*r  seiiduij;  the-  rdurri  messaj;**  lo  t  fie-  eallnij; 
ohjee  t .  r  he1  al^e.rithm  «*r«ses  the  informal  ion  flow  inslaru*-. 

E.  A  PKOCRAM  EXAMPLE 

A  program.  «euisisiinj>  of  e  lasses  (‘I.  (*2  anti  C'i.  and  tlie-  eor- 
r*‘spt)iidiiij;  inforiii.tt  ion  flow  templates  are  shown  in  figure  2. 
Objects  Ol.  02  ami  02.  are  instance's  ol  (*].  (!'J  and  (*,*{.  re- 
speelivelv.  (  lass  (‘1  eleiilres  a  general  program  til  1  be  hum  of 
an  inil  iah/.at  ion  procedur*'.  The  ohjeet  variafileSl  is  sialic  allv 
bound  to  l  lie  see  u r if  \  class  <  *(  )N  |-  1 1  )|-.!\'|  I A  b.  I  Ju*  inil  iali/.at  ion 
proieelure*  invokes  f  and  ^  in  objects  02  and  <)!i.  reaper  t  i\ ejv . 
Sine*'  the  inil  iali/at  ion  procedure  is  aiiloinat  icallv  invoked  at 
office  l  insj  ,ml  iat  ion  time,  it  eloes  not  have  a  formal  caller  and 
i 'onseepienl  iv  r  he'  informal  ion  flow  limphite  has  neientrv  ill  U»e 

I  APOIM*  <  atc*j»or\  Note  that  t  fie  sv  mberbe  e  lass  expressions  in 
both  the'  IMI’OltT  anej  ST  \TK’  e  ,.»iej;e>r  its  <  eintain  a  term  for 
ae  e  niiiulat  in*;  t  fie  itnplic  it  inler-obje  <  t  flow  from  the  erhj.et  that 

I I  is  i.i  ni  iale-  ( >  I .  lor  1  hr  example,  we  will  .i*"  im.e  1  hat  t  lie  e  lass 
of  1 1*  |s  iinplie  it  How  i--  | .(  )\\  .  ^i*ie  c  02  I  is  e  a  Heel  w  it  hill  a  loop. 

;  In-  s(  e  ur M  v  variable  O.M.i  oiin,'|ii>inliii}i  P)  Of  T  pai.ime-ti-r  i. 
i-  ia.tr  keel  w  il  h  an  (  ■  ) 

(  ‘lass  (  *2  deli  lies  e\  port  I'd  plot  eel  u  re  f  and  objee  I  v  a  ria  ble  S2 
w  h  ie  h  is  bou  im]  to  (  ()  \  I  1 1 )  f  A  I  I  A  1 . .  I  r  e  p|,n  the  v  a  I  lie  in  S*J 
w  it  Ii  IN  parameter  X  and  returns  the  old  value  ol  s2  lor  Ol’T 
p.iranw-ler  \.  (lass  ( defines  <  Nporle»l  prtxedure  j;  and  object 
v  at  in  ble  S.'f  w  hie  h  is  bound  to  Sf.(  K  ET  «;  a  this  the  sepia  ri-  ol  IN 
parameter  a  to  S.i  and  returns  this  value-  for  our  parameter  b. 

Assume  that  SI  and  s2  have'  initial  values  70  ami  0.  resper- 
tivelv  When  Ol  is  ins|  an)  iati-d.  the  information  flow  instance- 
for  t  h<*  in  it  iali/at  ion  proe  eefure  iv  e  real  eel  \\  hi*  It  e  a  <  op\  ol  the 
I  nlor  li  iat  iim  How  template'  for  1  lie  proeedufe  and  the  initiah/.a 
t  mu  proeeebne  i1-  autoinal  ie  alb  invoked  02. f  is  tailed  in  1  lie- 
boelv  ol  I  lie  while  loop  with  actual  IN  parameter  a  (  I  10). 
The  rum  I  line-  al*;or  it  Ii  in  dele  r  mines  the-  <  l.nus  lor  the  i  in  pin  it 
inter-ohje-e  1  flow  and  actual  IN  parameter  a  from  the  inlorina 
\  ion  How  i  n  si  .i  in  v  (in  t  Ins  *  as<-,  both  are  (  <  )  \  I  II)  I' A  I  I  A  I  .)  .hki 
(hen  attae  h  these  classes  lo  the  message.  'I  lie  under  hinj;  iimv 
saj'e*  passinj;  s\:-te'in  sends  the*  m<*.ssaj;c  lo  ohjeet  02. 

When  02  reteives  the  message,  the  algorithm  *111^1  ant i.itcs 
,t  new  iuletriuat  ion  How  mstame  based  <m  the  mfoi  mat  ion  How 
template  ami  replace’s  all  the  ex  <  urrent  es  of  (.implicit  and  lx 
in  the  install*  c  with  < !()  \  I-  1 1 )  (A  I'  I A  L.  'Hie  information  flow 
instance  at  this  point  is  as  follows; 


CLASS  Cl 
slate 

SI  :  integer  of  security  class  COM  IDKYi  I  \l,; 
in  it  iali/.c 

var  i  ,  a  :  integer: 
begin 

i  :  SI: 

while  i  10(1  <lo 
begin 

a  :  i  ■  2; 

02.1  (IN  a.  OUT  i) 

end: 

if  i  15(1  then  OX g  (IN  i,  OUT  Si); 
end  inil iali/.c; 
end  Cl ; 


CLASS  C2 
state 

52  :  integer  of  security  class  CONKIDENTIAL: 
procedure  I  (IN  x  :  integer;  OUT  >  :  integei); 
begin 
y  :  S2; 

S2  :  x 
eu<i  (; 
end  C2; 


CLASS  C.t 
state 

s:i  :  integer  of  security  class  SECRET: 
procedure  g  (IN  a  :  integer;  OUT  1.  :  integer); 
begin 

s:;  ;  S3  •  a  •  a; 

I)  :  S.i; 
end  g. 
end  03; 


Tlie  information  flow  template  for  Cl. initialize 
EXPORT 
IMPORT 

02  f  (IN  a,  OPT  i) 

implicit  CONFIDENTIAL  •  02.f.i(-) 

O'  init. implicit 

a  CONFIDES  !"l  AL  ■  02.1  i(  ■ )  init  .implicit 
o:i  g  (IN  i,  opt  Si) 

implicit.  _  CONF  IDENT! \l.  i  02. f.i(' ) 

O'  init . i r 1 1 p  1  i c  it 

i  CONI'  IDKNTI  VI,  02.l.i(i)  m  init .ituplic it 

STATIC 

Si  CONFIDENTIAL  •  CONFIDENTIAL 

0  ( )2.(.i(  * )  o,  OXg.Sl 
ij-  init . i tit p lie  it 


The  information  How  template  for  C2.f 
EXPORT 

f  (IN  x;  OPT  \) 

\  CO.NFIDI'.N TIAh  0:  f. implicit 

IMPORT 

STATIC 

S2  CONFIDENTIAL'  CONFIDENTIAL 

i;'  f.x  (]i  (.implicit 


The  information  flow  template  for  <’3.g 
EXPORT 

g  (IN  a;  OPT  I.) 

h  SECRET  ;  g. implicit 

IMPORT 

STATIC 

S.!  SEC  ill'.  I  SECRET  >j  g.a  O'  g. implicit 


figure  2.  \  n  I'.xaneile  Program 


EXPORT 

I  (IN  \;  OUT  >) 

>  COM  IDKNTI  \L 
IMPORT 
STATIC 

52  CONFIDENTIAL-  CONFIDENT! \l. 

Since  I  lie  flow  equation  for  52  in  lit"  ST  VI  I C  <  alegm  v  go  a  tan 
tees  tliis  tc:  lie  a  sei  tire  invocation,  the  execution  ol  I  is  initialed. 
The  value  of  S2  lire  oities  I  It)  and  OUT  parameter  v  lu  c  nines  (I. 
Also,  t  lie  i  lass  of  \  (  CONI  I  DI'.N  I  IA  I .)  is  deterimiii'd  from 
t  lie  informal  ion  flow  instance.  I  [ion  I  lie  t er minat ion  <>l  tin- ex¬ 
ec  ution.  tin  algorithm  erases  the  information  ||mv  insi.un  e  ami 
the  message  passing  x\ stem  sends  the  return  message  i„  ( )| 

Will'll  Ol  receives  the  return  message,  the  algorithm  adds 
(.ONI  1 1  If.  N  l  I  A  I,  (the  i  lass  ol  tin-  return  v  al  lie  i)  III  all  the 


s\  mholic  c  las-,  expressions  vv  lii(  h  c  out  ain  02  I  i(  •  )  in  llieinloi- 
mation  How  instance  loniiing 

EXPORT 

IMPORT 

02.1 1 IN  a.  OUT  t) 

implicit  CO\ EiDENTI  \  I.  •  ()2.l.i() 
a  CONFIDENTIAL  ()2.l.i() 

o;;.g(lN  i.  out  si) 

implicit  CONI-  IDENTI \l,  ■  02. [.:(•) 
i  COM- IDEM  I  Al,  02. f  i(  ) 

STATIC 

SI  COM- IDENTI  Al.  •  CONI  IDEM  I \l. 

■I  02  I  i(  )  :  O.t.g  SI 

ami  the  mini  mat  ion  How  is  ccrtilied.  (Note  that  tl  the  i  lass  of 
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Ol'T  parameter  \  ol  tin*  return  ines-age*  had  been  SM’ffLl, 

1  lie  flow  equation  loi  SI  would  have*  become 

SI  COM-  IDKNT1AI.  *  SKCUKT  :  <)2.f.»(  ■ )  Oii  -g  S  I 

and  i lit’  riin-t iint1  algorithm  would  have*  detet led  the  flow  viola- 
t  ion.) 

Alter  the  resimipl  ion  ol  t  he*  execution  in  ()  1 .  i  Ihtoiiio  0  and 
the*  hnd\  of  the  while  loop  is  again  executed.  This  lime.  02  1  is 
railed  with  actual  IN  parameter  a  (  0)-  I  he  message*  carries 

l  he  value  ol  a.  the1  class  ol  a  (  (  O.M*  ID  I' A"  1  IAD)  and  l  lie  class 

lor  1  he  implic  it  inter-object  How  (  COM*  IDI  A  I  IAL). 

'|  fie  algorithm  certifies  the1  information  flow  to  procedute  I 
of  02  ,jnd  upon  completion  ol  execution.  I  returns  \  (  110) 

and  its  s«-c  lit i t \  <  |,is».  (  (.  O.N |-  II )I*A  1  I  \ L)  to  the*  initiali/a- 

i  ion  pincedme  o|  ()!  Since  the*  (ondition.il  expression  of  the 
wlnle  statement  is  false,  the  loop  leiiiiinales  lin.illv.  since  i  he 
<  ondit  ional  e  xpression  ol  I  hr  it  sialeinent  i*  false,  1  he  exec  ut  ion 
tei  initiate’s  1 1 oi  malls 

\v  ;i  sec  one)  example*,  suppose*  the*  niiliai  value*  of  S)  is  M). 
Again.  1  he  u  liile  si  a  lenient  in  mi  nates  normal  l>  aim  1  la*  s<c  cum! 
ii,  ration  However,  i  has  tlie  value*  Mil)  in  the  if  statement  and 
():*,. a  is  invoked.  The  algorithm  places  the  class  of  i  (  (  (>\ 

M  l)K.\TI  \L)  and  the  class  oi  the  implicit  inter-object  How  ( 
COM-  IDI-ATI \L)  in  the  message.  I  pon  a  receipt  of  the  mes¬ 
sage  at  ()d.  t  hr  algorithm  instantiates  i  lie  informal  ii»ii  How  tem¬ 
pi, it  e  lor  g  and  r  rphic  e*»  all  tin*  <>t  c  m  unices  ol  g.a  and  g.iniplic  it 
with  fOM'IDI ATI  XL  lonuing 

i:\roRT 

Si  IN  .i:  <>*  I  *') 
h  sl-.(  If  I  T 
IMHOHT 
STATIC 

s:j  SKCilKT  •  shcllhi. 

Since*  the  How  to  S!’,  is  cerliliccl.  the  exec  in  ion  is  (allied  out. 
Mlc'i  g  lei  minutes  norinallv.  ihe  leturn  message*  is  c  oust  i  ijrtecl 
which  contains  the  value  ol  OhT  parameter  li  and  its  -re  m  its 
c  lass  Sl*.( 'if  ITT  and  1  he*  message  is  sent  to  01. 

In  Ol.  the*  algoiillnn  icplaces  OTg.SI  with  >1.1  If  K  1  and 
ihe  infoi  mation  flow  instance  lux  nines 

KXPOHT 

IMPOllT 

()2.I(IN  it .  OPT  i) 

implicit  COM  IDI  ATI  \h  02.1  if-) 

COM- IDI-ATI \L  l)2.l.i{  ■ ) 
o:;.g  IN  i.  OPT  si ) 

iin pin  it  (OxMDIATDh  021  i|  ) 
i  COM-  IDI-ATI  \1.  02. 1. if  ) 

STATIC 

s|  (  t'M-IIH  \  I  I  \  I.  >l.<  lil.'l 
( )'J  t  i  (  )  j  flow  v  mla!  ion  ■  •  •  J 

I  fn  algmis  inn  drlei  1-  ,»  1 1« »\*.  X  i . » l  i  1  H < 1 1  However  a-  me  lit  loiieif 
in  -re  1  ii  ih  | ).  I  he  s  \  v*(  in  j  ,|  mnu  n  -pm  1  1  In  t  1  mi  In  t  lie  iim-i  and . 
*■  Hu  c  1  lie  ill  v  cm  .i  1  mil  c  anting  t  he  c  I  ioi  »-  the  l.et  *-l  alrmenl  « *1  I  hr 
ill  it  i.ih/.il  mil  pine  *  d  UK  nl  (  >  1 .  1  lie  exec  ill  ion  mu -l  l»e  lrnnin.il *-d 
,i-  if  ini!  1 1 1 1 1 g  has  happe  ned.  Ol  licift  i-*r.  mu*  hit  ol  mloi  :i i.i  1  uni 
(the  1  i  1 1 1 1 1  ol  ial-ilv  ol  I  lie  i  «»lnhl  mrial)  i"  •'fill  1c*  the  um-j  lei- 
iiiin.d  [ < m 1 1 hi  1  fl 1 1 1 * )  Till"  i  mild  In  an  undf'.fc  t«*d  liow  v  iolation 
i  h  j  m  ■  i  i  d  mg  tin  llif  c  I.i  -  "  ol  i  . .  i  t*l  tin-  i  hai  <i  iM  c*  ol  the  u^ei. 


F.  CONCLUSION 

I  his  paper  ha--  present  rd  .ui  ini  urinal  inn  flow  i  or  t  ihe  at  inn  mec  h- 
anisin  lor  an  dist  ri hilled  ohjec  l  oi  rented  s\Mrtn.  I  lu*  rm*c*lianism 
is  a  combination  e,|  c  cuopile- 1  ltnc*  analysis  and  nin-liiiu*  cerlili 
cation  with  Die  following  -alicnt  I<*.i1uk*s: 

|.  Inlonnalion  flow  secuntv  c  lire  k"  are  clone  oi*l\  at  message* 
passing  1  line. 

2.  Object  variables  encapsulated  bv  an  object  are  static  all1 
bound  to  secmils  classes.  Ollier  progi  am  variables  c  an  be 
eil  her  d\  natnicaliv  or  statically  bomid  to  m-cijmIv  classes. 

.*{.  K.k  li  exported  procedure  in  an  object  can  be  compiled 
and  ils  ‘‘internal  securilv  established  totalis  independent 
of  other  exported  procedures. 

Inlonnalion  flow  semantics  were  presented  lor  selec  ted  pro¬ 
gramming  constructs.  Work  in  progress  consists  of  extending 
tin*  algorithm  to  allow  ioi  el\  namicalK  bound  object  variables. 
We  are  also  investigating  dillerent  wa\s  lo  cope  with  the  piob- 
lein  ol  illegal  inlortrial  ion  How  from  variables  in  a  c  ondil  innal 
expression  to  the  user,  caused  h\  system  generated  error  mes¬ 
sages. 
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APPENDIX:  The  OompHe-Tiine  Algorithm 

This  section  dcMiihcs  I  he  <  ompile-iiine  algoiilhm 

form  informal  ion  How  t<*mplale 

width  generates  an  inloi (nation  how  I c*i 1 1 1 ) l<i  1  ('  lor  expoitiil  pm 
(('dnrcs  ol  an  object.  The  loilow  mg  programming  const  i  w  «u  «■ 
«issu  uir;l: 

1.  de<  lurutioii  st  dlement  (the  declaration  n|  ixpoiiid  proce¬ 
dures  anti  lot  <il  variables). 

2.  assignment  statement. 

*».  compound  statement. 

1  it  statement, 

w  li i It*  si  alctncitl 

(».  procedure  in\ot at ion  atemenl .  and 

7.  end  statement  ol  tlu*  pi  ot  cdure  di »  laral  mji. 

'I'h is  algorithm  is  applied  to  each  statement  ol  a  procedure  be¬ 
ing  compiled.  STACK.  <  il.OH  \L.  sTYIIC  and  TKMPLATK 
are  globi:1  compile-time  variables.  The  following  iuit iali/at ion 
is  done  piior  to  its  upphi  at  ion  to  .in  cxpoited  procedure  in  an 
objei  t : 

1  'Hie  ('lit  r’.es  in  S(!  and  KYI*  for  each  object  variable  y  are 
crrated  and  initialized  as 

SC  \  security  class  of  t lie  objei  l  variable 

i;xr;>  mil 

STATIC  true. 

2.  Tin*  i » reprocessor  renames  invoi  aliens  of  the  ‘-nine  exin- 
nal  procedure  from  different  places  in  the  text  in  mdei 
to  make  ail  calls  dMimt  Then  entiles  c  ni  ms|m  aidi'ig  m 
all  the  eMemalU  invoked  pioiedutes  are  tiealed  in  i lie 
I \1 PONT  integer)  «»l  ITA1P!  \TP.  for  «-\«niiple.  it  the 
pi  in  ed  lire  being  compiled  is  PKOC  and  an  exiiin.il  pio- 

<  nliiic  0.g(IN  j  , . i,,.  OCT  . s„)  is  invoked 

in  PlfOC.  1  lit-n  these  entries  aie 

O.gfIN  X| ...  -r,,..  Ol'T  i1B.| . /„) 

implicit  M  LL 

/,  M  LL 
j,„  M  LL. 

.‘L  Ol.O|L\L  and  S  TACK  are  initialized  to  PPOC.implii  it 
and  LOW  .  respei  i  ivelv 


Th»*  algorithm  is  stated  below. 

procedure  |o;m  inlniin.il  u»n  flow  template 
(S  .  si ,i t emmi ; 

var  S(  T,\  I  ’  :  .ii  i  .i\  *  >1  ml  ioI'u  <  las*-  e\pn  --ion . 
var  \  :  set  ol  variables;  LOOP  :  Look  an): 

var 

Y  1 .  \  '2  :  sfi  (  |  v.n  iahle-; 

SCI.  2.  T,\  I*  i  :  ,ni  «i\  i  >|  s\  uibolii  i  l.isv  i  '-si  on 

ClI A\OKD  :  boolean: 

( TL  letup  :  sennit)  variable: 
begin 

case  S  of 

S  “procedure  I’lJOC 

(IN  f  \  :  vai  t>  pe  of  security  class  < ',»  : 

Sk  :  v.u  1  v  pe  of  security  class  <  : 

OCT  i/|  :  \.n  Ivpe  of  security  class  Ctl  . 

\f„.  :  \«i!  1  \  p i ■  of  security  class  Cv„  )’ 

begin 

for  i  :  l  to  k  do 

if  j,  has  a  ”  det  la i at  ion  ji.iit 
then 
Ix-Kin 
SC  i,  : 

KM’  J,  :  I’ |{<)( 

STA  CK '  s,  :  (rue 

oml 
else 
Im'KII* 

SC  r,  :  I’U (>('./,: 

STATIC,  r,  :  I.iIm- 

t'liil: 

for  i  1  to  hi  <lo 

if  v  Ini'*  ii  ‘I  dri  l.i r <■  1  mil  ill 

I  Ill'll 

'Cj.  :  ‘  : 

I .  \  I ’  //.  :  M  I.I.. 

^  I  \  I  I  (  //.  :  1 1 1  i  i  ■ 

oiiil 
I'lso 
l><*"in 

'»(’  I,.  :  M  1,1,: 

ST  VI  l( '  ij.  :  I.iIm- 
I'lut 

(■ml: 
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"v;ir  «i,  :  \ .1 1  t\pe  uf  security  class  (  ,|  : 


ii,  :  \  <1 1  1  \  |  n  *  of  sci  lllily  i  lass  : 

Infill 

for  i  I  lo  i  do 

if a,  iui*-  ,i  "C(l"  ilci  l.i r.il ion  | i.i r i 

t  In'll 
Infill 

>(  a,  :  ( 

K\T  a.  :  M  I.I. 

STATIC  a,  l rue 
end 
else 
lie-in 

SC  ii,  :  Ml.l.: 

STATU '  a,  l.iKe: 

•■lid: 

I'lid. 

S  "l>  :  I  (ii  i . i  !„.)'■ 

’  Assinriiii'iil  SUilomenl 
iM'fiiii 

if  STATIC  I) 

I  In'll 

lu'^in 

\'  :  0: 

I  AI’  Ii  :  I  AI'  I.  SC  ii,  .  .  SC  ii 
■-  SI  \(  K  •  (d.Olt  \l. 

<■■1(1 
else 
In-Kin 
V:  {I,}. 

S( '  Ii  :  S  C  ii,  SC  a ... 

:  stack  oi.ohai, 

i’lid: 

i'lid: 

S  "li('j>iii  olid 

I'I’K’ih 
\  :  0. 

for  i  :  I  lo  in  do 
Ix’Kill 

form  infoi'iiMl  ion  How  I ompl.it o 
( s', .  SC.  IAI',  VI.  1,001’): 

V  :  V  A  1; 

i'lid. 

i'lid: 


S  “if  K  I  lion  s,  {else  .s,}" 

Ui'K'ii 

STAi  K  |oi'-li( Ii): 

SCI  •  sc. 

lonn  mloi  nnil  ion  How  tempi. tie 

(.s, .  SCI.  KM’.  VI.  I.OOI'); 
if  SL>  ■  0 
t  In'll 
I’t'Kiii 
s(  "j  :  SC: 

lot  iii  inlorni.il  'oil  How  leinpl.ttr 

I SCJ.  TAT.  \  1.0(11’). 

olid 

clso 

\  J  :  0. 

if  \  K  ill  (VI  Vi) 

( Ill’ll  SC  \  :  SC  I  \  SC  J  \ 

else 

if  x  iv  in  (\  |  (VI  \  _’) 

1  lion  SC  x  :  SC  1  \  •  SO  x 

olso  SC  x  :  SCJ  x  ;  SC  x  : 

S'!'  ACI\  pop 
i'lid: 

S  "while  K  do  S: ' 
lioo'in 

CK  :  M  I.I,: 
repeat 

CM \NCKI)  :  fiiKi': 
if  <  K  (Cl.  :  K) 

t  ill'll 

Ix'fiii* 

CK  :  CK  :  T. : 

(  1 1 A  N  C  i  I  a  1 )  :  I r  no 

I'lul: 

ST ACK.pusli(CK): 

SCI  :  SC: 

I  AT  I  :  TAT: 

lorm  inlnrin.it ion  How  teinpl,ile 
(S.  SCI.  I  AT.  V.  1  rue): 

if  sc  ■  ■  ;sc  sci) 

t Ill'll 

Ix'Kiii 

SC  :  SO  SCI 
ell  Well):  true 
end: 

sT  U  K  pop: 

until  I A  T  T  \  T  I  and  lint  (II  \Md  I): 
(d.Olt  \l.  :  (d.Olt  \l.  :  I.OHI.  CK: 
end: 
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S  ~0.r(1N  -T| . j-j.Ol'Tt/, . II,,,)" 

lic^ill 

On  O.j;  i-nti)  in  ilu-  IMPORT  catcRor) 
ticnin 

mill  "  *  STACK  ■:  Ol.OllAI.”  in  iinplii  it; 

for  nil  x  ill  IN  pain  meters  ol  O.j;  <lo 
if  not  STATU '  x 
tin'll 

.idi!  SO  x  to  t lie  s\  inlinln 
i  lii'-i'  expression  tor  x: 

else 

if  ilii'  enti_\  lor  x  is  "x  M  1.1. 

t linn  rcpl.no  that  wiili  “x  SC  x  ; 

end: 

V  :  0: 

for  nil  \  ill  OUT  parameters  ol  l).i*  <lo 
Wniii 

if  not  STATIC)  V  :  V  {>  1- 
if  Tool’ 

t  In-11  letup  :  O.u  )  ( • ) 
else  temp  :  O.R.)  : 

if  S  TA  TIC  \ 

t  lion  TIN  I*  >  :  TXT  \  ■:  ti'iiii'  S  TAC  K 
■  Ol.OllAI. 

else  SC  \  temp  S  TACK  Ol.OllAI.: 

(■lid. 

cmi; 

S  -1-11(1  I’KOC 

lic,u,ili 

fill'  nil  X  'I:1  li  tli,i>  — •  I  VI  l<  x  inn  ltd 
it  l.\l’  x  Mil  tlicn 
I ■  I ■  o  x  ’  x  I  AT  x 

in  I  In-  S  I  \  I  It  '  i  ,i ti  "hi  \ 

III  Tl  M  1*1.  \1  I 

for  nil  x  ill  Ol’T  |i.n  .mu  li  I'  nl  I  MMX  do 
pliuc  "x  SC  x  ”  in  ilii'  lAI’OU  I  i  .Iiir.oi) 
nl  T l-Al PI.  VI  K. 

olid. 

<•11(1  i  axo: 

(>nd  for  in  ililnl  mat  mu  lln\(  template. 
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ABSTRACT 

This  paper  explores  the  differences  between 
monolithic  and  distributed  Trusted  Computing 
Bases,  using  as  an  example  an  actual,  system 
new  in  the  final  stages  of  development.  For 
each  of  the  differences  discussed,  the 
approach  taken  in  the  system  is  briefly 
described  and  motivated.  The  paper  includes 
a  description  of  the  security  policy  of  the 
system  and  its  correspondence  to  the  Bell  and 
LaPadula  model. 


1 .  BACKGROUND 

The  need  for  trusted  computing  systems 
which  process  data  at  multiple  security  lev¬ 
els  is  widespread  in  defense  related  pro¬ 
grams.  Such  systems  have  been  an  active 
research  area  for  over  ten  years,  with  the 
result  that  worked  examples  of  tightly  cou¬ 
pled***  multi-level  secure  systems  have  been 
demonstrated  [Fra83,  Whit74].  A  set  of  cri¬ 
teria  for  the  architecture  of  multi-level 
systsjus  v-\ o 0 i F* lied.  "^'Va 0  DoD  COI£““ 

puter  Security  Center  [DoDssj.  These  cri¬ 
teria,  known  popularly  as  the  "Orange  Book", 
also  address  the  assurance  that  must  be  pro¬ 
vided  that  the  architectural  criteria  have 
been  mat.  At  the  highest  Orange  Book 
category,  Al,  formal  specification  and  verif¬ 
ication  are  required  at  the  design  and  policy 
levels. 

The  requirement  for  handling  data  at 
multiple  levels  goes  beyond  the  usual  operat¬ 
ing  system  concern  of  local  users  sharing 
local  resources;  it  is  also  being  imposed  on 
a  current  generation  of  embedded  distributed 
systems.  Even  though  no  worked  examples  of 
secure  distributed  systems  exist,  the  same 
criteria  are  being  applied  in  the  belief  that 
such  systems  are  a  natural  extension  of  the 
previous  work  on  tightly  coupled  operating 
systems.  This  paper  reports  on  the  security 
architecture  of  one  of  the  first  secure  dis¬ 
tributed  systems  to  be  attempted:  the  issues 
raised,  the  approaches  taken,  and  the  lessons 
It  irned . 

1.1  Terminology  and  Basic:  Concepts 

A  Hulti-Level  -Secure  (MLS)  computer-  .sys¬ 
tem  protects  information  o:i  the  basis  of 
security  laoels  which  are  attached  to  the 

*  This  paper  presents  the  opinion  of  its 
authors,  which  ir,  not  necessarily  that  of 
Unisys  or  of  the  Department,  of  Defense. 

**  i  o:\T.nrly  Svsti-m  Development  Corporation 

Tightly  coupled  is  used  hero  m  the  sense 
that  the  system  can  be  modelled  as  a 
single  state  machine. 


components  of  the  system.  System  components 
include  both  data  objects  and  active  com¬ 
ponents  cf  the  system;  but  a  given  component 
may  play  both  roles  at  different  times  in  its 
lifetime.  For  the  purposes  of  this  discus¬ 
sion  labels  are  assumed  to  be  associated  with 
a  component  at  the  time  it  is  created  and  to 
retain  their  initial  values  for  the  life  of 
the  component.  As  is  usual,  components  them¬ 
selves  have  components,  leading  to  a 
hierarcnical  structure  that  spans  'system'  to 
individual  variables  and  program  statements. 
The  granularity  with  whicli  a  sys;tem  protects 
information  is  determined  by  the  level (s)  of 
components  that  carry  labels.  All  current 
Mbs  systems  cease  explicit  labelling  at  some 
point  in  the  component  hierarchy,  with  the 
result  that  lower  level  components  inherit 
implied  labels. 

Each  active  component  of  the  system, 
e.g.  a  process,  a  service,  a  subsystem,  has  a 
domain  of  execution  which  defines  the  set  of 
data  objects  to  which  it  may  potentially  be 
granted  access.  "Access"  has  system-specific 
meaning,  but  current  systems  focus  on  "read 
access"  and/or  "write  access".  Read  access 
describes  any  system  defined  interaction 
between  components  in  which  information  flows 
from  a  data  component  to  an  active  component, 
while  write  access  describes  the  converse. 
The  domain  of  an  active  component  can  be 
further  broken  down  into  read  and  write 
domains,  which  will  normally  be  expected  to 
overlap.  Active  components  interact  either 
by  sharing  data  objects  across  domains  (e.g. 
a  shared  file) ,  or  by  exchange  of  data 
objects  between  domains  (e.g.  a  message  sys¬ 
tem  or  input/output) . 

A  system  is  MLB  if  all  interaction 
between  components  preserves,  with  some  level 
of  assurance,  the  conf inement.  of  data  objects 
to  the  read  and  write  domains  of  active,  com¬ 
ponents  with  compatible  labels.  A  confine¬ 
ment  failure  is  known  as  a  compromise .  The 
compatibility  of  active  component  labels  and 
data  component,  labels  is  determined  by  the 
following  domain  confinement  rule: 

A  component  (either  active  or  data)  may 
potential  1 y  receive  information  from 
another  component  marked  at  any  level 
"dominated  by"  its  own  label,  where 
"dominates"  is  a  system  specific  partial 
ordering  of  labels.  This  implies  that 
the  label  of  an  active  component  must 
dominate  the  labels  of  each  data  com¬ 
ponent  in  its  read  domain-,  and  also  that 
the  label  of  an  active  component  must  bo 
dominated  by  the  label  of  each  data  com¬ 
ponent  in  its  write  domain. 

The  domain  confinement  lule  restates  the 
basic  properties  of  the  well-known  Bell  and 
LaPadula  model  (BI.P7G)'  the  simple  security 
property  and  the  * -property. 
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c.  Parts  of  the  security  state  may  be 
replicated  at  several  devices  in  order 
to  increase  system  availability.  The 
system  security  constraints  must  then 
assert  consistency  of  values  for  all 
replicated  components  of  the  security 
state  regardless  of  where  they  are 
stored. 

Although  not  normally  viewed  as  part  of 
a  system's  security  state,  the  types  and 
operations  defined  within  the  TCB  can  be 
viewed  as  data  va Ivies  of  a  distributed  TCB 
which  are  replicated  everywhere  they  are 
used.  The  best  example  of  this  is  the  type 
that  defines  the  values  held  by  security 
labels;  if  this  definition  varies  from  site 
to  site  within  thi  TCB  then  a  meaningful 
definition  of  policy  enforcement  is  not  pos¬ 
sible.  Likewise  the  operation  that  computes 
the  partially  ordered  comparisons  between 
labels  must  be  implemented  with  the  same 
semantics  at  each  site.  This  view  of  types 
and  operations  as  data  is  derived  from  an 
object  oriented  [Gold83]  model  of  computation 
and  it  reduces  the  distributed  TCB  concern 
that  similar  things  be  accomplished  in  simi¬ 
lar  ways  to  yet  another  data  consistency  con¬ 
straint.  This  data  changes  so  slowly  that  an 
automated  protocol  is  not  usually  used  to 
guarantee  consistency,  but  rather  consistency 
is  addressed  by  trusted  distribution  of 
software  - 

2.2  Trusted  Paths  between  TCB  Components 

within  a  single  domain  TCB,  it  can 
always  be  assumed  that  TCB  local  data  have 
been  defined  by  trusted  code  and  that  parame¬ 
ters  passed  in  a  procedure  call  have  been 
sent  by  trusted  code.  When  reasoning  about 
the  correctness  of  a  single  domain  TCB,  one 
need  not  question  whether  internal  communica¬ 
tions  is  being  spoofed. 

A  distributed  TCB  must  provide  trusted 
paths  between  its  distributed  domains  in 
order  to  achieve  similar  assurance.  This 
usage  of  the  term  "trusted  path"  is  a 
strengthening  and  generalization  of  its  usage 
in  [D0D8B] .  As  used  here,  a  trusted  path 
offers  the  following  guarantees: 

a.  A  message  received  from  a  trusted  path 
originates  from  a  trusted  source.  This 
property  can  be  supported  in  stronger 
form  by  authentication  of  the  exact 
identity  and  security  attributes  of  the 
originating  component. 

b.  A  message  received  from  a  trusted  path 
contains  the  same  value  that  was  sent. 
This  guarantees  that  message  data  have 
not  been  modified  by  untrusted  entities. 

c.  If  messages  have  security  labels,  then 
the  label  on  a  received  message  has  the 
same  value  that  was  sent.  This  guaran¬ 
tees  that  message  labels  have  not  been 
modified  by  untrusted  entities. 

d.  An  optional  property  is  the  preservation 
of  message  order  on  pairwise  trusted 
paths.  (This  property  also  prevents 
replay  of  messages.)  It  is  optional 


because  it  may  be  expensive  to  implement 
and  difficult  to  verify.  Further,  it 
may  not  be  required  to  support  TCB 
correctness. 

2 . 3  Trusted  Protocols 

A  distributed  TCB  will  need  to  trust 
some  of  its  protocol  interpeters,  possibly  at 
several  different  ISC  levels,  for  any  of  the 
following  reasons: 

a.  To  implement  the  trusted  path  concept  of 
the  previous  section.  Trusted  path 
could  be  incorporated  into  the  services 
offered  by  interpreters  of  standard  pro¬ 
tocols  at  the  transport  level  and  below. 
In  the  absence  of  such  a  standard,  a 
system,  specific  end-to-end  protocol 
layer  can  be  inserted  at  the  transport 
level  using  cryptographic  authentication 
techniques.  An  example  of  the  latter 
approach  is  given  later.  The  design 
verification  costs  for  these  two 
approaches  vary  considerably:  verifica¬ 
tion  of  standard  protocols  is  quite  dif¬ 
ficult,  but  given  an  acceptable  formal 
model  of  encryption,  end-to-end  imple¬ 
mentations  of  trusted  path  that  do  not 
guarantee  delivery  are  substantially 
easier  to  verify. 

b.  To  implement  system  level  atomic  state 
transitions.  If  the  system's  security 
relevant  integrity  constraints  are  not 
very  strong,  this  may  not  pose  a  prob¬ 
lem.  Otherwise  it  may  be  necessary  to 
design  application  level  protocols  with 
the.  goal  of  taking  the  entire  system 
from  one  consistent  state  to  another. 
We  will  see  examples  of  both  cases  later 
in  this  paper.  Application  level  proto¬ 
cols  defined  for  this  purpose  can  be 
exceedingly  difficult  to  verify. 

c.  To  provide  system  level  concurrency  con¬ 
trol.  Protocols  such  as  the  two  phase 
commit  can  be  viewed  as  implementing  a 
distributed  lock  mechanism.  For  the 
most  part,  concurrency  controls  are  use¬ 
ful  to  help  in  achieving  security 
relevant  atomic  state  transitions,  but 
they  are  frequently  also  useful  in  con¬ 
trolling  non-security  relevant  transi¬ 
tions  in  the  system.  (Recall  that  our 
definition  of  security  does  not  address 
denial  of  service.) 

2 . 4  Hierarchical  Trusted  Computing  Bases 

Distributed  TCB  components  may  be  imple¬ 
mented  as  applications  software  on  devices 
which  also  support  untrusted  applications,  in 
which  case  a  local  reference  monitor  is 
required  to  prevent  interference  with  trusted 
operations.  In  addition,  jf  the  distributed 
TCB  components  handle  multi-level  data,  the 
local  reference  monitor  must  provide  a 
multi-level-secure  environment.  So  a  distri¬ 
buted  TCB  may  be  implemented  as  a  hierarchy 
of  TCDs  in  which  the  system  level  TCB  relies 
upon  correct  policy  enforcement  of  local  TCBs 
for  its  own  correct  policy  enfer cement. 


It  i s  important  to  note  that  the  domain 
confinement  rule  constrains  the  domains  of 
active  components  from  containing  data  com¬ 
ponents  with  the  potential  for  compromise, 
regard  less  of  the  actual  compromise  that  the 
component  might  cause  in  a  less  constrained 
domain.  The  actual  behaviour  of  the  com¬ 
ponent  could  be  compromise  free  in  the  less 
constrained  domain,  depending  on  it's  inter¬ 
nal  logic  and  its  actual  (as  opposed  to 
potential)  pattern  of  references  to  other 
components.  It  would  even  be  possible  for  a 
component  to  be  compromise-free  with  respect 
to  its  domain  In  one  given  state,  while  caus¬ 
ing  compromise  in  domains  with  other  states. 
An  active  component  is  called  compromise 
correct  if  it  is  compromise  free  in  all  pos¬ 
sible  domains  in  which  it  can  function  as 
part  of  the  overall  system.  Compromise 
correct  components  can  be  exempt  from  the 
domain  confinement  rule  without  changing  the 
MLS-ness  of  the  system. 

A  Trusted  Computing  Base  (TCB)  is  the 
set  of  system  components  which,  in  order  for 
the  system  to  be  MLS,  must  function  correctly 
in  the  roles  they  play  in  the  system  archi¬ 
tecture.  In  principle  the  TCB  can  encompass 
all  of  a  system's  components,  but  it  is  very 
costly  to  provide  assurance  of  confinement 
using  this  approach;  since  each  component, 
and  each  interaction  between  components,  must 
be  examined.  In  other  words,  each  component 
must  be  compromise-correct.  In  practice, 
this  approach  is  limited  to  small  dedicated 
systems  with  a  static  set  of  components.  For 
larger  systems,  particularly  those  which  are 
open  to  the  introduction  of  now  components  by 
untrusted  users,  a  better  approach  isolates  a 
small  subset  of  components  into  a  Reference 
Monitor  [And72]  which  enforces  the  domain 
confinement  rule.  The  TCB  then  becomes  the 
reference  monitor  components  and  a  small  set 
of  trusted  components  which  are  compromise 
correct . 

In  order  to  prevent  untrusted  components 
from  interfering  in  the  correct  execution  of 
reference  monitor  code,  it  is  customary  for  a 
reference  monitor  to  have  a  privileged 
domain  of  execution  which  includes  not  only 
the  domains  of  all  subjects  but  additionally 
contains  objects  not  in  the  domain  of  any 
subject  in  the  system.  These  reference  moni¬ 
tor  private  objects  normally  contain  signifi¬ 
cant  portions  of  the  system  security  state 
such  as  labels,  clearances  and  passwords.  In 
some  implementations,  reference  monitor 
private  objects  are  not  themselves  labelled. 


2.  WHY  DISTRIBUTED  TCBS  ARB  DIFFERENT 

This  section  discusses  the  difference 
between  a  traditional  monolithic  TCB,  where 
all  TCB  components  share  a  domain  and  commun¬ 
icate  by  shared  variables  and  procedure 
calls;  and  a  distributed  TCB,  where  TCB  com¬ 
ponents  are  distributed  over  a  network  and 
communicate  by  exchanging  messages.  All  of 
the  classical  TCB  security  issues  must  be 
addressed  by  a  distributed  TCB;  but  some 
issues,  such  as  formal  verification  of 
correctness,  are  made  more  difficult  by  dis¬ 
tribution  of  TCB  components.  Other  issues. 


such  as  trusted  paths  between  TCB  components, 
are  new  to  distributed  TCBs  (or  at  least  have 
been  implicit  in  previous  models) . 

The  increase  in  complexity  that  results 
from  distributing  a  TCB  forces  increased 
reliance  on  architectural  arguments  for  secu¬ 
rity  assurance,  due  to  the  weaker  assurance 
possible  from  formal  arguments.  Perhaps  this 
is  only  more  evident  for  the  distributed  TCB 
case  than  has  been  the  case  for  single  domain 
TCBs.  We  have  always  relied  on  architectural 
arguments  for  hardware  assurance  of  domain 
separation,  and  for  locally  reliable  storage 
and  transmission  of  data.  Analagous  func¬ 
tions  in  a  distributed  TCB  may  be  implemented 
in  software,  but  they  are  no  less  complex  nor 
easier  to  verify. 

The  following  subsections  explore  the 
five  primary  differences  that  we  have  been 
able  to  identify  as  requiring  extra  attention 
when  building  a  distributed  TCB.  Briefly, 
they  are  fragmentation  of  the  TCB  domain, 
trusted  paths,  trusted  protocols,  hierarchi¬ 
cal  TCBs,  and  fault  tolerance. 

2 . 1  Fragmented  TCB  Domain 

In  a  monolithic  TCB  the  concept  of  a 
secure  state  can  be  expressed  by  an 
integrity  constraint  on  the  values  held  by 
security  relevant  data  objects  within  the 
TCB's  domain,  for  example  that  current 
accesses  of  subjects  to  objects  are  con¬ 
sistent  with  a  security  policy  based  on  the 
security  labels  associated  with  those  sub¬ 
jects  end  objects.  All  components  of  the 
security  state  are  immediately  available  and 
stable  in  their  values.  It  is  possible  for 
the  monolithic  TCD  to  guarantee  that  the 
security  state  changes  one  well  defined 
step  at  a  time  and  that  after  each  change  the 
security  state  meets  it's  integrity  con¬ 
straints. 

In  a  distributed  TCB  the  security  state 
of  the  system,  rather  than  being  collected 
into  a  single  protected  domain,  is  distri¬ 
buted  across  various  devices  of  the  system. 
Maintaining  integrity  constraints  on  a  dis¬ 
tributed  security  state  is  complicated  in  the 
following  ways: 

a.  It  is  difficult  to  check  the  system 
security  integrity  constraints  at  a  sin¬ 
gle  device,  since  remote  components  of 
the  system  security  state  are  not 
obtainable  without  delay  and  arc  not 
guaranteed  stable.  It  may  still  be  pos¬ 
sible  to  assert  meaningful  integrity 
constraints,  but  this  situation  causes 
an  overall  weakening  of  the  constraints 
that  can  be  asserted. 

b.  Instead  of  a  totally  ordered  sequence  of 
state  transitions,  a  distributed  TCB's 
state  history  is  only  partially  ordered 
due  to  the  possibility  of  concurrent 
transitions  at  different  devices. 
Again,  it  is  still  possible  to  state 
meaningful  integrity  constraints,  but  a 
careful  analysis  of  potential  interfer¬ 
ence  between  concurrent  transitions  is 
needed . 
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The  relationship  between  the  system 
reference  monitor  and  the  reference  monitors 
of  individual  devices  ear.  be  subtle.  The 
local  TCLi's  interpretation  of  subjects  and 
objects  bears  no  necessary  relationship  to 
the  distributed  TCB's  interpretation.  This 
is  particularly  true  if  tne  system  TCB  does 
not  view  reference  monitor  data  structures  as 
as  objects  which  are  labelled  and  subject  to 
access  controls.  In  a  distributed  TCB,  sys¬ 
tem  level  reference  monitor  data  in  likely  to 
be  application  level  data  to  the  local  refer¬ 
ence  monitor.  Another  example  of  the  cogni¬ 
tive  gap  between  local  and  system  TCBs  is 
that  active  components  viewed  as  ui. trusted 
with  respect  to  local  policy  may  well  be 
trusted  with  respect  to  the  ryscem  policy, 
e.g.  system  level  access  control  decision 
making  and  system  level  audit  data  recording. 


Clearly  there  is  a  need  for  some  "glue" 
tie  the  various  components  of  a  distri- 


consi.utant  system  level 
One  of  tile  most  important 
the  globally  consistent 
security  .labels  and  their 
This  was  identified  earlier  as 
integrity  constraint  over  ropli- 


to 

buteri  TCB  into  a 
reference  monitor, 
such  avhesivus  is 
representation  of 
comparisons 
a  form  of 

cated  data.  Consistent  barrelling  need  not 
mean  identical  'labelling,  except  for  the 
external  representation  of  labels  that  are 
exchanged  over  a  network.  Labels  internal  to 
a  device  may  have  increased  granularity  as 
long  as  homomorphi.sra  is  maintained  between 
internal  and  external  forms;  i.e.  a  well 
defined  mapping  butv;eor»  labels  exists  Lhci-- 
preservea  the  dominance  relation.  This  free¬ 
dom  to  increase  label  granularity  cat.  be 
quite  useful,  particularly  in  the  area  of 
added  compartments  and  subcompartniepts . 


2 . E  Fault  tolerance 


Unlik.v  a  monolithic  TCB,  which  is  either 
in  service  or  out  of  service,  a  distributed 
1CB  continues  to  enforce  a  security  policy 
when  some  of  its  c.  mponents  are  not  in  ser¬ 
vice  Tne  normal  case  for  a  distributed  sys¬ 
tem  is  that  something  is  broken  somewhere. 
In  consequence ,  a  distributed  TCB  must  sup- 
po?;t  "fail-secure"  properties  in  its  design, 
verification,  and  architecture.  Fail  secure 
properties  assert  that  no  compromise  occurs 
even  when  some  components  are  unavailable. 

Desirable  security  properties  are  fre¬ 
quently  "safety"  properties;  i.e.  properties 
that,  assert  the  preservation  of  a  secure  sys¬ 
tem  state.  As  1 ony  as  the  failure  states  of 
the  computation  arc  secure,  one  need,  not  show 
that  a  computation  makes  progress  in  order  to 
show  that  it  is  secure.  This  observer  ion 
allows  the  sidestepping  of  a  number  of  known 
difficult  verification  problems,  such  as  ter¬ 
mination.  in  a  distributed  TCB,  the  granting 
of  an  access  request  may  involve  a  chain  of 
actions  by  different  components.  If  the 
chain  is  broken  by  component  failure  or  com¬ 
munication  failure  the  result  is  denial  of 
service,  not  compromise  Erid-to-cnJ  checks 
which  do  not  require  reasoning  about  the  con¬ 
current  interaction  of  components  may  suffice 
to  demonstrate  fa  >  .1  -securuiioes  without 
guaranteeing  actual  do  ivory  of  a  service. 


Although  not  required  by  the  security 
policy  presented  in  this  paper,  denial  of 
service  is  of  serious  concern  to  many  end 
users  of  trusted  systems,  in  some  cases  of 
higher  concern  than  security  policy  enforce¬ 
ment.  A  trusted  distributed  system  cannot  be 
allowed  to  shut  down  when  one  of  its  com¬ 
ponents  fails.  The  system  must  continue  to 
provide  at  least  partial  policy  enforcement 
for  as  long  as  possible. 

The  classical  reliability  technique  of 
replicating  data  and  processing  can  be 
app) ied  to  distributed  TCBs.  As  mentioned 
previously,  one  result  of  such  replication  is 
the  necessity  lor  synchronizing  protocols  to 
manage  updates  to  replicated  security 
relevant  data.  Another  complication  is  that 
device  level  secure  initialization  and/or 
recovery  becomes  complicated  by  the  necessity 
to  synchronize  the  stave  of  the  local  TCB 
d-»ta  with  the  system  TCB  state. 


3 •  A  REAL  EXAMPLE  OF  A  DISTRIBUTED  TCB 

Each  ot  the  issues  raised  ir  the  previ¬ 
ous  section  has  boon  addressed  in  the  design 
for  a  classified  system  now  in  the  final 
stages  of  development.  For  the  purposes  of 
this  paper  we  will  call  this  system  NRM, 
which  stands  lor  Network  Relerence  Monitor. 
The  following  description  is  greatly  simpli¬ 
fied  in  order  to  focus  attention  only  upon 
the  security  architecture  of  the  NRM. 

NRM  consists  of  a  family  of  devices 
which.,  when  added  to  a  packet  switched  net¬ 
work,  collectively  enforce  a  security  policy 
on  the  exchange  of  messages  betw’oen  hosts  on 
the  network.  Encryption  is  the  basic  domain 
separation  mechanism  of  NRM.  The  device 
typer  in  this  family  consist  ot  the  follow¬ 
ing  : 

a.  Secure  Network  interface  (SMI} s  One  of 
these  devices  interfaces  each  network 
host  to  the  network.  It.  is  transparent 
because  it  presents  a  host,  interface  to 
the  network  and  a  network  interface  to 
the  host.  This  device  only  passes  mes¬ 
sages  to  or  from  a  host  after  a  NRM 
security  policy  check  described  below. 
A  BN!  encrypts  a  message  before  sending 
it  to  the  network  or  decrypts  a  message 
uel  ivered  from  the  network  using  a  key 
that  ir  shared  only  by  the  source  and 
destination  hosts  c,  the  massage .  This 
key,  in  association  with  other  security 
related  dara,  establishes  a  bidirec¬ 
tional  cryptographic  connect  ion  between 
the  two  hosts .  a  .‘INI  can  manage  a  large 
sea  or  cryptographic  connections. 

b.  %y  Control  Center  (KCC) :  This  device 
generates  a  p.m;  key  to  be  used  for  each 
new  cryptographic  connection  and 
securely  distributes  a  copy  of  this  key 
to  the  source  and  destination  hosts 
associated  with  the  connection. 

c.  Security  Control  Center  (BCC) :  When  a 
host  rends  a  message  through  a  SN1,  and 
the  SN1  does  not  currently  manaas  a 
cryptographic  connection  between  the 


Finally,  the  /^-component  states: 

Only  the  System  Security  Officer  can 
change  the  security  relevant  data  in  the 
SCO's  databases. 

3 . 2  MODEL  AND  CORRESPONDENCE 


source  and  dcstinaton  hosts  of  the  mes¬ 
sage,  the  SNI  requests  the  establishment 
of  a  now  cryptographic  connection  by 
sending  a  request  message  to  an  SCO. 
The  SCC  mediates  this  request  by  check¬ 
ing  for  inclusion  of  the  candidate 
message's  security  level  in  the  security 
ranges  of  both  the  source  and  destina¬ 
tion  hosts.  SCC  mediation  also  includes 
a  check  that  the  message 1 1-  source  and 
destination  hosts  are  .included  m  each 
others  discretionary  access  control 
lists.  If  botli  of  the  above  checks  are 
passed  then  the  SCC  directs  the  KCC  to 
establish  a  cryptographic  connection 
between  the  two  hosts. 

3 . 1  NKM  SYSTEM  SECURITY  POLJ.CV 

The  NRM  System  Security  Policy  has  com¬ 
ponents  that  jointly  control  the  establish¬ 
ment  and  use  of  crypto  connections  between 
pairs  of  hosts-  For  the  liRM  system,  the 
range  of  security  levels  associated  witii  each 
host  indicates  the  range  within  which  that 
best  can  communicate  (i.e.,  send  or  rece.ive 
messages) .  Each  crypto  connection  esta¬ 
blished  bv  the  NRM  System  has  associated  with 
it  e  single  security  level.  Tnus,  a  connec¬ 
tion  must  be  establish!  ;  for  each  level  at 
which  a  pair  ol  hosts  wishes  to  communicate . 

By  first  contru. 1 ing  access  of  hosts  to 
connections,  and  then  controlling  the  use  of 
those  connections  by  the  hosts,  the  NRlt  Sys¬ 
tem  oi  i'eelix  eiy  controls  the  flow  oi  classi¬ 
fied  information  between  hosts.  To  accom¬ 
plish  this,  a  security  policy  has  been 
defined  with  mandatory  and  discretionary  com¬ 
ponents  t.o  control  the  access  of  hosts  to 
connections,  and  an  ente.’echy*  component  to 
control  the  use  of  those  connections.  A 
fourth  component,  the  delta  component ,  writ¬ 
ten  /^-component ,  limits  changes  to  the  sec's 
security  relevant  databases. 

The  mandatory  component  of  the  NRM  Sys¬ 
tem  Security  Policy  states  that ; 

A  host  may  have  current,  access  to  a 

crypto  connection  only  : f  the  security 
level  of  that  connection  falls  within 
the  security-level  range  of  that  host. 

The:  discretionary  component  of  the  security 
policy  states  that.: 

A  host  may  have  current  access  to  a 

crypto  connection  only  if  that  host  had 
ui  sci-ctionn  >-y  permission  for  that  con¬ 
nection  v.hen  the  access  was  first 
approved 

The  enteleehv  component  of  the  security  pol¬ 
icy  states  tnat: 

A  host  may  send  or  receive  messages  over 
o  crypto  connection  only  if  it  has 
currert.  access  to  that  crypto  connec¬ 
tion. 

—  Entolechy:  the  realization  of  form-giving 
cause  as  contrasted  with  potential 
existence.  (Webster's  New  Collegiate 
Diet i onary) 


In  order  to  meet  the  Orange  Book 
requirements  for  an  A1  class  of  certifica¬ 
tion,  it  is  necessary  to  demonstrate  that  the 
design  of  the  system  ,as  expressed  in  both 
the  Formal  Top  Level  Specif ication  and  the 
Descriptive  Top  Level  Specification,  is  con¬ 
sistent  with  a  formal  mathematical  model  of 
security.  For  the  NRM  system,  the  model  that 
was  chosen  is  the  Bel l-LaPndula  model,  modi¬ 
fied  where  necessary  to  more  precisely 
express  the  NKM  security  policy.  This  sec¬ 
tion  describes  the  correspondence  between  the 
model  and  the  NRM  system  design. 

3.2.1  Subjects  and  Objects 

The  subjects  in  the  NRM  System  are 
hosts.  A  hoot  is  defined  to  include  sub¬ 
scriber  hosts  which  are  directly  attached  to 
SNIs,  NRM  control  nodes  (i.e.,  SCCs  and 
KCCs) ,  or  the  internal  host  within  each  SNI 
whose  function  is  to  coordinate  with  the  con¬ 
trol  nodes. 

The  NRM  System  objects  are  the  connections 
between  pairs  of  hosts.  A  connection  indi¬ 
cates  the  potential  for  two  hosts  to  communi¬ 
cate  with  each  othci  by  sending  and  leceiviny 
messages  via  their  SNIs.  Each  connection  is 
uniquely  identified  by  a  host-pair  and  a 
security  label,  e.g. 

( ( hostl , host 2 } , label) 


In  the  NRM  system,  security  level  is 
defined  exactly  as  it  is  in  the  Bell_LaPadula 
model.  That  is,  a  security  level  is  a  pair 

(classif ication,  set-of-categorics) 

where  classification  is  totally  ordered,  and 
categories  are  not  ordered.  Security  levels 
are  partially  ordered  by  the  'dominates' 
relation. 


3.2.3  Access  Modes 

The  Bell-LaFadula  model  identifies  four 
types  of  access  which  a  subject  may  have  to 
an  object:  read,  append,  write,  and  execute.* 
In  the  NRM  system,  sending  a  message  via  a 
connection  is  viewed  as  an  append  to  the 
connection-object,  while  receiving  a  message 
via  a  connection  .is  viewed  as  a  road  from  the 
connection-object.  Since  all  connections  in 
NRM  are  two-way  (send  and  receive) ,  write 
access,  which  includes  both  'read'  and 
'append'  capabilities,  is  the  only  mode  of 
access  applicable  to  NRM  connections. 

*  Note  that  'read'  means  read-only, 

'append'  moans  write-only,  and  'write' 
means  read-and-write .  This  awkward  usage 
has  historical  origins. 


3.2.2  Security  Level 
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Consequently,  write  access  is  the  only  access 
mode  implied  in  the  NRM  System's  current 
accesses  and  discretionary  permissions. 

3.2.4  Current  Access  Set 

Rather  than  being  stored  in  one  central 
location,  the  NRM  System  Current  Access  Sot 
is  distributed  among  the  SNls,  and  is  imple¬ 
mented  as  connection  state  records  stored  at 
each  SNI. 

3 . 2 . 5  Access  Permission  Matrix 

In  the  NRM  system,  discretionary  permis¬ 
sion  is  defined  for  pairs  of  hosts,  e.g. 

(hostl ,  host2) 

This  represents  discretionary  permission  for 
hostl  to  have  write  access  to  any  connection 
object  which  has  hostl  as  one  end  point  and 
host2  as  the  other  endpoint.  This  form  is 
equivalent  to  a  set  of  discretionary  permis¬ 
sions  as  represented  in  the  Bell-LaPadula 
model:  for  a  permission,  (hostl,  host2),  the 
equivalent  entries  in  the  Bell  LaPadula 
model's  Access  Permission  Matrix  would  be  all 
entries 

(hostl,  ( (hostl , host2 ), 1 abel ) ,  write) 
where  label  is  any  security  level  defined  in 
the  system. 

The  Access  Permission  Matrix  is 

represented  in  a  SCC  data  base  as  a  set  of 
Access  Control  Lists  which  represent  inclu¬ 
sion  or  exclusion  by  host  name  and  inclusion 
or  exclusion  by  named  group.  For  a  NRM  system 
which  consists  of  a  single  domain,  the  Access 
Permission  Matrix  is  centralized,  since  each 
SCC  in  the  domain  has  a  complete  copy  of  the 
discretionary  permission  databases.  However, 
in  multi-domain  systems,  the  matrix  is  dis¬ 
tributed  across  domains,  with  each  domain 

having  only  those  entries  of  concern  to  the 
hosts  in  that  domain. 

3.2.6  Level  Function 

The  Level  Function  (f)  of  the  Bell- 
LaPadula  model  is  a  triple  of  functions: 

fS  =  Maximum  security  level  of  a  subject 

fc  =  current  security  level  of  a  subject 

fO  =  Security  level  of  an  object 
Two  of  these  functions  are  meaningful  in  the 
NRM  System:  the  fS  function  and  the  fO  func¬ 
tion.  Rather  than  store  only  a  maximum  level 
for  a  host,  and  then  also  store  an  attribute 
which  indicates  if  the  host  is  trusted,  the 
SCC  data  base  contains  a  range  of  levels  for 
each  host.  Untrusted  hosts  have  single  level 
ranges  and  trusted  hosts  have  multi-level 
ranges.  There  is  no  concept  of  hosts  chang¬ 
ing  their  "current"  level,  so  the  fC  function 
is  defined  to  be  the  same  as  the  fS  function. 
For  objects,  the  fO  function  indicates  the 
level  of  a  connection,  i.e.,  the  label  com¬ 
ponent  of  a  connection  identifier 
( ( hostl , host2 ) , label ) . 


3.2.7  Security  Policy 

As  described  above,  the  NRM  security 
policy  has  a  mandatory  component,  a  discre¬ 
tionary  component,  a  ^-component,  and  an 
entelechy  component.  The  mandatory  and 


discretionary  components  satisfy  the  Bcli- 
LnPaduln  security  properties,  while  the  /\- 
component  and  the  entelechy  components  have 
no  direct  counterparts  in  the  Uell-Laradula 
model . 

Si mpl_o_ Seeuri  ty  prr.pcrt  y 
Since  the  mandatory  component  requires  tnat 
the  connection-object  label  must  be  within 
the  range  oi  the  host,  the  maximum  le-'el  of 
the  host's  range  (i.e.,  IS  for  that  host) 
dominates  the  level  of  the  connection-object, 
thus  satisfying  the  simple  security  property. 

*^j'roperty 

By  the  mandatory  component,  subjects  which 
have  single-level  ranges  can  only  have 
current  access  to  connection-objects  at  that 
level.  This  is  sufficiently  restrictive  to 
satisfy  the  Uell-Laradula  *-property.  How¬ 
ever,  note  that  subjects  which  have  multi¬ 
level  ranges  can  have  current  access  to 
connect xon-obj ects  at  any  level  within  their 
range,  which  is  a  violation  of  *-propert.y. 
In  other  words,  multi-level  hosts  are  trusted 
subjects.  The  NRM  mandatory  component  is 
somewhat  more  restrictive  than  the  *-property 
in  that  the  *-property  allows  trusted  sub¬ 
jects  to  have  write  access  at  any  level  dom¬ 
inated  by  the  subject's  level,  whereas  the 
NRM  mandatory  component,  limits  such  access  to 
only  those  levels  which  are  in  the  subject's 
range. 

Discretionary  Poli cy 

This  component  ot  tne  nkk  security  pojicy  is 
expressed  in  such  a  way  that  it  is  only  at 
the  time  the  access  is  granted  by  the  scc 
that  the  system  ensures  the  existence  of  dis¬ 
cretionary  permission.  After  this  point  it 
is  possible  that  the  discretionary  permission 
can  be  invalidated  in  the  SCC,  while  the 
current  access  is  still  active  (i.e.,  a  per¬ 
mission  still  exists  in  the  SNI's  table).* 
Other  than  the  revocation  issue,  thin  com¬ 
ponent  of  the  NRM  policy  is  identical  to  the 
Bel 1-LaPadula  discretionary  property. 

/jy -Property 

Although  the  Tranquility  Principle  focused 
solely  on  changes  to  an  object's  security 
level,  a  more  general  statement  of  the  prin¬ 
ciple  would  be  that  changes  to  the  security¬ 
relevant  data  of  the  TCB  cannot  be  made 
except  by  agents  which  are  trusted  to  violate 
tranquility.**  This  is  in  fact  what  the  /\- 
component  addresses.  lr.  the  NRM  system,  the 
only  agent  trusted  to  change  the  security¬ 
relevant  data  Is  the  System  Security  Officer. 


*  Note  that  this  is  very  similar  to  the 
situation  which  exists  in  some  operating 
systems,  where  a  user's  current  access  to 
a  file  is  not  revoked  when  and  if  the 
discretionary  matrix  entry  is  deleted. 
Instead,  the  user  will  not  bo  aware  that 
discretionary  permission  has  been  revoked 
until  he  tries  to  access  the  file  at  a 
later  time  after  giving  up  his  current 
access. 

**  Note  that  inclusion  of  such  a  principle 
as  a  required  property  of  the  model  would 
address  the  problems  pointed  out  by 
McLean  in  System-L . 
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3.2.G.3 


Knt  o]  ccliy 

The  entolechy  property  was  added  to  the  NRM 
security  policy  primarily  because  of  the  dis¬ 
tributed  nature  of  the  system,  because  tha 
decision-making  described  in  the  property  is 
implemented  in  software,  and  because  this 
decision-making  is  crucial  to  the  enforcement 
of  security  in  the  system.  In  an  A1  operat¬ 
ing  system,  the  analogous  mechanism  would  be 
the  memory-mapping  hardware,  which  is  usually 
considered  to  be  outside  the  scope  of  the 
Bcll-Lal’uduia  model  and  formal  specifications 
thereof.  In  the  NRM  system,  the  enforcement 
of  sntclechy  is  the  primary  charter  of  the 
trusted  software  within  the  SNls,  and  without 
the  correct  enforcement  of  this  property,  the 
decision-making  of  the  SCCs  would  be  .of  lit¬ 
tle,  if  any,  value. 

3 . 2  .  U  Rules  ol  Operation 

In  tlie  Bel 1 -baPadula  model,  the  possible 
state  changes  of  a  system  are  described  by 
•rules'  which  correspond  to  specific  actions 
which  are  performed  by  the  NRM  system.  This 
section  identifies  and  briefly  describes 
those  actions. 

3. 2. 8.1  Modifications  of  the  Current  Access 
Ret 

In  the  NRM  system,  modifications  to  the 
current  access  set  arc  accomplished  by  each 
SN1  as  updates  to  its  connection  table. 
Adding  a  connection  to  the  table  is 
equivalent  to  adding  an  access  to  the  Current 
Access  Set.  Removing  a  connection  from  the 
tabic  is  equivalent  to  removing  an  access. 
The  SNT  adds  connections  to  its  table  only  it 
they  have  arrived  via  a  trusted  path  from  the 
SCO  via  the  KCC.  Removal  of  permissions  is 
done  either  in  response  to  a  command  received 
from  the  SCC  (again,  on  a  trusted  path) ,  or 
as  part,  of  an  LRU  replacement  mechanism  when 
the  tabl e  is  full . 

3. 2. 8. 2  Modifications  o£  Sub j ects ,  Objects, 
and  Levels 

In  the  SCC,  two  of  the  transactions 
which  the  Security  Officer  may  perform  are 
Create-Site  and  Deloto-Sitc.  Create-site 
accomplishes  the  addition  of  a  subject  host. 
The  addition  of  a  new  subject  to  the  system 
implicitly  adds  to  the  system  all  connection 
objects  which  have  that  subject  as  one  of  the 
endpoints.  Conversely,  the  transaction 
Delete-Site  involves  the  removal  of  subject 
hosts  (and  implicitly  their  associated 
objects)  from  the  SCO's  database.  The  secu¬ 
rity  range  of  a  subject  is  established  when 
the  subject  is  added  to  the  system,  and  can¬ 
not  be  modified  once  it  is  established.  The 
only  way  that  a  subject's  range  can  be 
changed  is  to  delete  the  subject,  and  then 
add  the  subject  with  a  different  range  speci¬ 
fied. 

The  level  of  a  connection  is  an  .integral 
part  of  the  identity  of  the  connection,  and 
all  possible  connections  between  subjects  are 
viewed  as  existing  as  long  as  both  subjects 
exist.  Thus,  it  makes  no  sen  e  to  change  the 
love]  of  an  object,  and  no  provision  is  made 
in  the  system  for  accomplishing  this. 


Mod i f i cat  ions  ol  t  lie  Pi scrcticnary 
Matri x 

In  the  SCC,  transactions  have  been 
defined  lor  adding  or  removing  entries  from  a 
set  of  relations,  which  implement  discretion¬ 
ary  Access  Control  Lir.tr. :  Include-Host, 
Lxclude-Host,  Group,  Includc-Group,  and 
Excl ude-Group .  From  the  point  of  view  of 
modifying  the  discretionary  matrix,  these 
transactions  are  somewhat  obscure  in  their 
results.  For  example,  adding  a  host  pair  to 
the  Include-Host  relation  will  result  in  that 
host  pair  being  added  to  the  (abstract)  dis¬ 
cretionary  matrix  only  if  the  same  host  pair 
is  NOT  an  entry  in  the  Fxcludo-Hor.t  relation. 
Identifying  a  host  as  a  member  of  a  group  may 
add  or  delei e  entries  lrom  the  (abstract) 
discretionary  matrix,  depending  on  what 
entries  are  currently  present  in  the 
Includc-Group  and  Kxclude-Group  relations. 

3.2.9  The  Basic  Security  Theorem  and  Induc- 
t. i on  Hypothesis 

The  forma]  specification  methodology 
being  used  for  the  NRM  system  is  the  Formal 
Development  Methodology  ( FDM) ,  developed  by 
System  Development  Corporation  [Sch85].  The 
FDM  specification  language,  Ina  Jo,  permits 
the  description  of  a  system  as  a  state 
machine.  The  theorems  generated  by  FDM 
demonstrate  that  the  system  starts  in  a 
secure  state,  and  that  each  state  transforma¬ 
tion  preserves  security,  as  defined  in  the 
criteria  and  constraints  of  the  specifics- 
t ion.  Tills  i f-  very  sitnilar  fc.o  the  appro-*r:h 
described  by  Bell  and  baFadula  in  their  dis¬ 
cussion  of  the  basic  security  theorem.  In 
[BLP70],  Bell  and  LaPadula  state  that  "...the 
Lasic  security  theorem  establishes  the 
'inductive  nature'  of  security  in  that  it 
shows  that  the  preservation  of  security  from 
one  state  to  the  next  guarantees  total  system 
security."  (p.  20)  Based  on  this,  it.  can  bo 
argued  that  verification  of  the  NRM  specifi¬ 
cations  demonstrates  that  the  NRM  system 
design  is  secure,  as  defined  in  the  Boll- 
I.aBaduia  model. 

3 . 3  FAULT  TOLLRANCD 

The  NRM  system  has  several  strategies 
for  continuing  to  piovido  service  to  applica¬ 
tion  components  when  a  NRM  component  lias 
failed.  These  strategies  include  load  shar¬ 
ing,  redundant  security  data  bases,  the  con¬ 
tinuation  of  existing  service  in  the  absence 
of  a  control  center,  and  secure  recovery  of 
failed  components. 

NRM  is  organized  into  control  domains 
which  partition  the  SNls  of  the  system;  i.e. 
each  SN1  belongs  to  a  control  domain  and  no 
SHI  is  in  more  than  one  control  domain.  Each 
control  domain  has  several  redundant  SCCs  and 
several  redundant  KCCs.  The  SCCs  of  a  domain 
share  the  domain  workload  according  to  a 
static  assignment  of  SCCs  to  SNls  as  a  pri¬ 
mary  server.  In  the  event  of  an  SCC  failure, 
the  SNls  which  view  the  failed  SCC  as  t  air 
primary  server  will  redirect  their  service 
requests  to  an  alternate  SCC,  again  according 
to  a  static  assignment  of  secondary  servers. 
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Since  domains  are  disjoint,  minimal  data 
base  information  is  shared  across  domains 
(primarily  the  identities  of  other  domains 
and  their  control  centers).  Inconsistency  of 
this  small  amount  of  data  across  domains 
results  in  denial  of  service,  not  compromise. 
Within  a  domain,  SCCs  maintain  identical  data 
bases  which  must  be  updated  concurrently.  In 
order  to  assure  data  base  consistency  across 
SCCs,  a  t.wo  phase  commit  protocol  [Gray7fl]  is 
used  for  data  base  updates  which  synchronizes 
update  requests.  Mo  updates  are  allowed 
unless  all  SCCs  are  availat’e.  This  pro¬ 
cedure  prevents  most  possible  causes  of  data 
base  inconsistency,  but  is  not  proof  against 
awkward) y  timed  failures  during  the  execution 
of  the  data  base  update  protocol.  Ke  assume 
that  such  failures  are  disabling,  and  that 
the  potential  inconsistency  will  be  identi¬ 
fied  during  a  secure  recovery  procedure  which 
compares  data  bases  with  other  SCCs.  A  much 
more  detailed  discussion  of  the  SCC  design  to 
assure  data  base  consistency  is  in  prepara¬ 
tion. 

In  the  case  where  all  SCCs  of  a  control 
domain  have  failed,  the  HUM  system  continues 
to  serve  application  hosts  vising  in  place 
crypto  connections,  but  no  new  connections 
can  be  established*.  for  important  or  fre¬ 
quently  used  connection; ,  the  SCC  keeps  a 
list  for  each  SNI  of  a  set  of  connections  to 
be  established  at  the  time  the  SNI  is  ini¬ 
tialized  . 

Perhaps  more  difficult  than  continuing 
to  serve  in  a  degraded  configuration  is  the 
problem  of  recovering  a  failed  component 
without  disturbing  the  system.  NRM  has  been 
designed  so  that  each  control  center  estab¬ 
lishes  consistency  with  the  other  control 
centers  in  its  domain  before  beginning  to 
honor  service  requests. 

3  -  'i  CONCURRENCY  ISSULS 

1 ’M  domain  can  be  viewed  as  having 
se,  .•!  ’tiCdl  regions  with  respect  to  con¬ 

cur.  activities  in  the  domain.  This  means 
•  •  vrm  system  operations  must  not  ovor- 

,  t’.or  in  time  when  they  involve  the 

tical  region.  Actually,  in  the 
1  improving  system  efficiency,  the 
„  allows  certain  race  conditions  in 

l eg i ;  t  are  fail-secure. 

The  most,  common  critical  region  in  a 
domain  is  a  crypto  connection:  SNIs  at  each 
end  can  concurrently  request  establishment 
from  different  SCCs.  The  resulting  i ace  has 
four  cases,  two  oi  which  permit  communication 
over  the  connection  and  two  of  which  do  not. 
It  was  decided  that  synchronization  of  SNIs 
to  prevent  this  race  had  too  high  a  cost  in 
network  traffic  and  reduced  domain  workload 
capacity.  Instead  the  broken  connection  is 
repaired  in  the  saint  way  as  any  other:  by 
repeating  the  connection  request. 


~*~Thc— actual  system  upon  which  NRM  is 
modelled  has  an  alternate  service 
capability  in  this  situation.  This 
capability  is  not  described  here. 


The  more  critical  region  is  the  SCC  data 
base,  in  which  only  a  single  data  base  update 
is  permitted  at  a  time.  A  two  phase  commit 
protocol  serves  as  a  distributed  lock  to 
assure  this.  It  would  have  been  possible  to 
define  finer  granularity  regions  in  the  SCI 
data  base,  say  at  a  file  or  record  level.  We 
decided  not  to  do  this  because  the  SCC  update 
rate  is  very  low  and  there  is  little  to  be 
gained  from  increased  concurrency  in  the 
region . 

Beyond  the  synchronization  concerns  of  a 
domain,  there  remains  the  difficulty  of 
assuring  the  correctnc;  of  a  domain  level 
operation  that  is  d.‘  .tributed  over  several 
devices.  Crypto  connection  establishment  is 
the  most  important  cf  these,  and  the  NRM 
design  relies  upon  control  over  cryptographic 
variables  as  an  end-to-end  check  upon  connec¬ 
tion  establishment  in  which  all  known  failure 
cases  are  compromise  free. 

Revocation  cf  existing  connections  is  a 
different  matter.  For  the  reasons  given  in 
Section  2,  it  is  not  possible  to  verify  revo¬ 
cation  in  the  presence  of  all  network 
failures.  Instead  a  number  of  increasingly 
painful  heuristic  procedures  are  employed 

3 . 5  Fragmented  TCP.  Domains 

The  NRM  depends  for  its  correctness  on  a 
consistent  intorpetat ior,  of  security  relevant 
types,  operations,  and  data  across  all  dis¬ 
tributed  components.  the  NRM  method  for 
assuring  this  consistency  begins  with  the 
controlleo  distribution  of  software  releases. 
Ft-cn  software  release  has  a  cryptographically 
derived,  checksum  which  is  checked  when  it  is 
installed  at  a  NRM  site.  Operational 
software  has  access  to  the  version  number  of 
the  release  currently  in  execution,  and 
release  nuir.ocrs  are  compared  between  sibling 
SCCs  when  an  SCC  is  initialized. 

3  -  £•  LOCA  TCH;, 

One  ar  the  cost  subtle  issues  in  the  NRM 
design  revolved  around  the  decomposition  of 
the  system  TCB  into  sets  of  trusted  com¬ 
ponents  that  execute  on  aiilerent  NRM  proces¬ 
sors.  Facn  such  processor  needs  a  local  TCB 
to  provide  isolation  tuv.ccn  the  trusted  and 
untrusted  functions  that  it  supports  anu  to 
provide  controlled  sharing  of  data  between 
trusted  components. 

One  of  the  earliest  NRM  design  decisions 
was  that  communications  between  distributed 
NRM  components  would  take  place  over  NRM 
crypto  connections.  one  nt  the  consequences 
of  this  decision  is  that  message  traffic 
between  Ni  M  components  carries  security 
labels  just,  like  those  carried  by  subscriber 
host  messages.  All  uialog  between  a  SCC  ar.a 
a  SNI  is  conducted  at  the  highest  level 
authorized  lor  the  subscriber  host  attached 
to  the  SNI.  This  convention  requires  tha* 
the  local  TCB  be  able  to  send  and  receive 
messages  at  multiple  security  levels,  and  to 
keep  message  data  separated  by  level  within 
the  local  processor. 


FUTURE  ISSUES 


The  security  kernel  for  the  SCC  and  KCC 
processors  has  a  traditional  security  archi¬ 
tecture  based  upon  a  secure  MULTICS  model. 
In  addition,  this  kernel  defines  and  enforces 
an  integrity  policy  [Biba77]  which  is  iso¬ 
morphic  to  a  dual  of  the  traditional  comprom¬ 
ise  policy,  i.e,  the  integrity  labels  are 
drawn  from  a  completely  disjoint  set  of 
labels.  The  ordered  part  of  the  integrity 
label  is  used  to  support  internal  trusted 
path  arguments  which  assert  that  high 
integrity  trusted  components  can  receive  data 
only  from  other  high  integrity  trusted  com¬ 
ponents.  The  sec/ KCC  kernel  does  not  define 
a  discretionary  policy,  but  the  unordered 
integrity  compartment.-,  are  assigned  in  such  a 
way  as  to  create  incomparable  integrity 
domains  for  different  TC5  subsystems.  This 
convention  enforces  a  least  privilege  discip- 
l’.ne  on  the  application  design. 

3.7  TRUSTED  PATH  PROTOCOL 

Originally,  the  URH  desion  was  based  on 
the  use  of  TCP  for  transport  of  messages 
between  distributed  trusted  components.  We 
found  TCP  lacking  for  <  number  of  security 
related  reasons  which  arc  described  in  this 
section . 

TCP  is  not  a  message  stream,  but  a  byte 
stream  which  may  deliver  bytes  in  different 
blocks  than  those  that  were  sent.  The  NRM 
design  adds  another  transport  layer  called 
Network  Support  Protocol  (IMP)  whose  purpose 
is  to  block  and  un' lock  messages.  NSP  imple¬ 
ments  a  massage  stream. 

TCP  connections  are  single  level.  The 
NRM  design  adds  a  security  label  to  all  out¬ 
bound  messages  ».hich  is  bound  to  the  message 
text  by  a  cryptographic  checksum.  Upon 
receipt  ol  a  message,  the  checksum  is  recom¬ 
puted  and,  if  it  compares  with  the  transmit¬ 
ted  value,  the  message  is  assign'd  the 
transmitted  label.  The  processing  to  accom¬ 
plish  this  is  organized  into  yet  another 
transport  layer  protocol  cal  lea  the  Trusted 
rath  Protocol  (NT).  IFP  transforms  HSP's 
single  level  message  stream  into  a  multi¬ 
level  message  stream. 

The  security  label  added  to  messages  by 
TPP  include:;  an  integrity  component  so  that  a 
high  integrity  receiver  of  a  TPP  message  car. 
know  with  high  contidence  that  the  sender  of 
the  utr.iiij.  .isb  labelled  high  in  integrity, 
l.iis  „at.  islie:;  the  source  authentication 
requirement  lor  trur-’-ed  paths. 

The  cryptograph ic  checksum  applied  to 
n essaycr.  by  '1  pp  is  computed  using  a  variable 
which  is  protected  in  a  local  TCB  kernel 
domain.  This  variable  is  shared  by  all  1JSP 
hosts  which  communicate  using  TPP,  and  is 
initialized  and  up dated  by  trusted  manual 
distribution.  fho  check  made  upon  receipt  of 
a  I PP  message  detects,  with  a  high  degree  of 
confidence,  unintentional  or  malicious  modif¬ 
ications  to  message  datj*. 

*  Since  TPP  is  at  a  higher  lc'c!  than  TCP, 
which  computes  its  own  unt.rustea 
checksum,  d  .tection  of  unintentional 
modification  should  be  quite  rare. 


4  . 


The  NRM  system  design  surfaced  and  dealt 
with  a  number  of  important  issues  that  dis¬ 
tinguish  distributed  from  monolithic  TCBs. 
There  are  a  number  of  issues  that  were  not 
dealt  with  in  the  NRM  design,  either  because 
they  do  not  arise  in  the  NRM  application 
domain,  or  because  the  NRM  design  sidestepped 
the  issue.  The  following  .sections  provide  a 
brief  overview  of  some  of  these  issues. 

4 . 1  Alternate  Connection  Models 

The  NRM  model  has  been  influenced  by 
current  communication  protocols  which  rely 
upon  positive  acknowledgement  and  retransmis¬ 
sion  as  the  fundamental  mechanism  for  assur¬ 
ing  reliable  delivery  of  messages.  This 

mechanism  requires  data  flow  in  both  direc¬ 
tions  between  the  heats  involved  in  the 
exchange  of  a  message.  This  is  the  fundamen¬ 
tal  motivation  for  the  NRM  convention  that 
read/write  is  the  only'  mode  of  access  of  a 
host  to  a  cryptc  connection. 

In  anticipation  of  applications  which 

use  a  different  set  of  protocols,  such  as  a 
trusted  reliable  network  layer,  it  would  be 
possible  to  define  read-only  and  write-only 
access  modes  to  a  crypto  connection  in  direct 
support  of  one-way  connections. 

4 . 2  Global! y  Shared  Local  Resources 

TMc  NPM  cicsicjn  ^ub3CL"ibc“ 

hosts  to  be  the  subjects  ot  its  policy.  If  a 
host  is  multi-level,  it  is  responsible  for 
the  separation  and  labelling  of  its  internal 
storage  objects.  NRM  wil.  assume  that  mes¬ 

sages  f  rora  such  a  host  are  correctly 
labelled.  When  a  distributed  system  is  con¬ 
sidered  in  which  the  subjects  are  local  sub¬ 
jects  executing  on  a  given  host,  such  as  a 
user  or  a  process,  ar.d  the  objects  are  local 
resources  on  a  possibly  different  host,  such 
as  a  file  or  memory  segment,  a  new  set  of 
issues  arise.  foremost  among  these  issues  is 
the  requirem.  t  for  local  ICtls  at  t  >.ch  of  the 
distributed  hosts  which  must  coordinate  pol¬ 
icy  decisions  with  each  other.  A  trusted 
multi-level  network  such  as  NRM  must  be 
assumed  to  connect,  the  local  TCBs .  Correct 
policy  enforcement  must  rely  on  end  to  end 
arguments  involving  both  the  local  policies 
and  the  network  policy. 

In  this  envi  roni.-.er’"  ■  nemt-r  ol  tradi¬ 
tional  issues  become  m-  fficult: 

a.  Subject  naming  co:  .  ns. 

b.  Object  naming  conventions. 

c.  Identification  and  authentication. 

d .  Aud l t - 

4.3  Mult,  ip,  e  TCB  Interaction 

In  a  distributed  world,  it  is  possible 
to  view  tin.  world  as  a  partial. y  ordered  set 
of  abstract  services,  which  is  exactly  what 
has  been  done  lor  communication  protocols  in 
the  1  NO  model.  fur  each  abstract  service  a 
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set  of  data  objects  and  end-point  entities 
can  be  defined  for  which  it  might  be  reason¬ 
able  to  define  a  security  policy.  NRM,  for 
example,  is  essentially  a  security  policy  for 
ISO  Level  3  network  service  (as  closely  as 
one  can  map  IP  into  the  ISO  model).  It  would 
be  absurd  to  define  a  security  policy  for 
each  abstract  service,  but  it  is  probably  not 
possible  to  adequately  address  the  security 
needs  of  distributed  applications  at  the 
level  of  a  single  abstract  service. 

In  the  end,  the  security  architecture  of 
a  distributed  application  will  require  both 
vertical  integration  of  TCBs  that  are  nested 
and  rely  on  the  policies  of  lower  level  TCBS, 
and  horizontal  integration  of  TCBs  that 
interact  with  each  other  as  peers  in  provid¬ 
ing  true  end-to-end  enforcement  of  an  appli¬ 
cation  leve’  policy. 
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Introduction 


This  paper  reports  on  a  tnree  year  project 
whiTi  at  the  time  ot  this  conference  will  be 
precisely  one  year  olu.  ihe  project  is  an 
ambitious  effort  in  the  tielus  ot  lormal 
specil  ication  ana  verification,  sottware 
engineering  support,  anu  security.  There 
arc  two  primary  goals  or  the  project.  The 
rirst  is  to  buila  a  short  term  workbench  to 
support  lormal  specil  ication  ana  veritica- 
tion  ot  secure  aistributeo  systems  in  a 
soitware  engineering  environment,  craving  on 
existing  tools  ano  techniques  wherever  pos¬ 
sible.  The  second  goal  is  to  oecign  a  long 
term  workbencn  which  signil icantly  advances 
the  state-ot-the-ar t  in  providing  integrated 
support  tor  the  oesign  ot  secure  Distributed 
systems.  The  project  is  structureo  in  three 
pnases:  studies,  short-term  workbench  ana 
long-term  design. 


background 

fvUii.;ackiyatiyi) 


The  pt-gect  is  meant  to  till  a  gap  in  the 
develop  opt  ot  lormal  systems  that  was  per¬ 
ceived  b.  the  RADC  secure  systems  community 
in  early  ..  ji>.  At  tha*  time  there  was  ongo¬ 
ing  work  devotee  to  the  oesign  ot  secure 
Distributed  databases  anu  secure  aistributeo 
operating  systen.s  but  there  were  no  projects 
nevoted  to  the  development  ot  tormal  specif- 
lcation  ano  verit ication  tools  to  tacilitate 
the  building  ot  such  systems. 


tms  concept  w a  •  not  lully  developed, 
let  alone  integrated,  into  conventional 
sottware  development  processes  such  as 
testing  ano  configuration  management. 

2.  The  limitations  ot  existing  tools  was 
especially  unacceptable  in  the  context 
ol  the  uevelopment  ot  large  distributed 
systems. 

3.  Fault  tolerance  ana  real  time  perfor¬ 
mance  are  issues  which  were  not 
addressed  in  existing  systems. 

assembl  ed 


The  project  is  a  joint  effort  of  four  com¬ 
panies  which  bring  an  interesting  mix  ot 
talents  and  experience: 

Sytek  -  specitication  ano  verit ication 
of  secure  systems  such  as  the 
NASA  RAF  14,  b] 

-  Muse  tool  enhancements  to  clas¬ 
sical  HDM  [6,7] 

-  nathemati cal  talent 

OKA  -  experimental  Ulysses  veritica- 

ti  on  system 

-  Ada  verif ication  contributions 

-  sous  specitication  ano  verifica¬ 
tion  [  b] 

-  extraoroinary  depth  ot  mathemat¬ 
ical  talent 

CCA  -  distributed  database  work  (SDb- 

1,  M'JLTIBASt,  i,um/dum) 

-  design  support  anu  sottware 
development  tools  (UUfcf,,  py) 


Lxistmg  lormal  tools  were  oeticient  in  a 
number  ot  ways: 

1.  For  the  most  piart,  the  }«radigms  tor 
lormal  specitication  ana  vei  itication 
were  aivorceu  tram  other  aspects  ot  the 
sottware  development  process.  HUM  11- 
31  is  a  notable  exception.  Jt  tries  to 
match  the  needs  or  soitware  development 
in  a  number  ot  ways.  Most  inger  tantly 
it  has  a  concept  ol  hierarchical 
oevejopment  that  matches  the  sottware 
engineering  layering  approach  to  com¬ 
puter  ano  network  architecture.  but 


KCA-ATL  -  Verlangen  verit ication  system 
[  9 ,1 0  J 

-  sottware  development  experience 


The  project  is  oivioed  into  tasks  as  tol- 
1  ows: 


1.  Temporal  properties  stuoy 

2.  Database  consistency  study 

3.  Fault  tolerance  stuoy 

4.  Survey  of  existing  tools  and  metho¬ 
dologies  and  exploration  oi  enhance¬ 
ment  c 

b.  Short  term  workbench 
b.  Long  term  tools  design 
7.  Adaptive  policy  specification 


This  work  was  supported  by  7\ir  torce  Systems 
Command,  Home  hir  Development  center  (HADC) 
urioer  Contract  1-30002- U6-C-0 263  . 
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Developments  to  gate 


As  of  this  writing,  June  iyb7,  study  tasks 
1,  2,  ana  3  are  completed  ana  work  unuet 
Task  4  is  in  progress. 


Task  1  was  lea  by  toward  Schneider  of  OKA. 
Tanj  a  cie  G  root  and  Dianne  Britton  ot  HUA  Alt 
tabs  contributed  to  the  stuoy.  We  summarize 
uel  ow  some  of  tne  highlights  of  the  rejiort, 
"'temporal  Properties  of  Distributed  Systems" 
1111. 


Our  model  oi  computation  consists  ot  a  col¬ 
lection  of  processes  that  interact  only  by 
passing  messages.  The  only  state  sharea 
between  any  two  processes  is  the  communica¬ 
tion  channel  between  tnem.  A  process  is  a 
sequence  of  actions  consisting  of  a  mixture 
of  communications  and  internal  computing. 

The  model  presumes  that  the  communication  is 
synchronous.  A  process  will  be  described  as 
a  set  of  traces,  where  each  trace  is  a  pos¬ 
sible  behavior  of  the  process  as  observed 
over  a  finite  period  of  time.  Thus  a  trace 
of  a  process  in  an  environment  is  a  finite 
sequence  oi  input  and  output  actions. 

The  various  kinos  of  temporal  properties 
have  been  grouped  into  3  categories: 

«  security 

«  Progress  (deadlock,  liveiock,  starva¬ 
tion,  liveness,  fairness) 

«  Determinism  (Concurrency  control  and 
race  conoit.ions) 

«  Keal-time  fjertormance  (resource  allo¬ 
cation  and  scheduling) 

•  Fault-tolerance  (restart,  recovery, 
reconliguration) 

.Security  We  have  developed  a  non¬ 
interference  mooel  of  security  in  the  con¬ 
text  of  a  hated  l.'vent  bystem  (KLb)  .  An  Kli> 
has  as  its  ingreaients  a  set  t  of  events,  a 
set  T  ot  traces,  a  jiartially  ordered  set  L 
of  security  levels,  and  a  1  unction  lvl  which 
maps  U  to  L.  Basically  the  mouel  says  that 
lot  an  arbitrary  trace  t.  and  level  1  the 
events  in  the  trace  of  level  1  or  less  are 
not  altected  by  other  events  in  tne  trace. 

Verilication  ot  security  is  complex  in  a 
system  with  many  processes.  This  complexity 
is  managed  by  inferring  noninterference  tor 
the  entire  system  trom  proofs  about  each  ot 
its  constituent  processes.  In  oroer  to  make 
this  inference  from  constituent  processes  to 
the  whole  system,  each  process  must  satisfy, 
in  addition  to  noninterference,  two  addi¬ 
tional  properties:  Determinism  ana  Univer¬ 
sality.  Determinism  asserts  that  the  output 
of  a  process  is  uniquely  determined  by  the 
state  at  the  time  of  its  invocation  ana 
Universality  asserts  that  Lor  any  state 
either  all  inputs  are  accepted  or  none  are 
accefJteo. 


Lotn  the  near-term  ano  the  long-term  tools 
suould  be  able  to  handle  security  proots. 

The  major  requirements  for  these  proofs  is 
to  identity  the  sets  of  events  ano  traces 
tor  each  process.  The  set  of  events  shoulo 
include  error  messages,  such  as  the  failure 
to  meet  a  real-time  req ui rement. 

Any  scheoulers  that  arbitrate  among  non- 
oeteem ini sti c  choices  must  be  trusted.  Nor¬ 
mally  these  schedulers  should  not  receive 
any  classiiied  information  on  which  to  base 
their  scheduling  decisions.  However  the  use 
or  scheduling  priorities  and  time- 
requirements  in  a  real-time  system  will 
sometimes  use  such  information.  Such 
scheoulers  must  be  shown  not  to  leak  this 
information. 


We've  beer,  success!  ul  in  specify¬ 
ing  liveness  in  the  context  oi  Verlangen. 

The  resulting  constructs  are  simple  anu  tne 
theorems  are  as  amenable  to  prooi  as  are  the 
theorems  we’ve  encountered  in  lormal  specif¬ 
ication  oi  security.  Thus  botn  the  near 
term  ana  long  term  tools  can  be  expected  to 
deal  with  this  aspect  of  progress  at  the 
highest  level  of  specir  ication.  Other 
aspects  of  progress  such  as  fairness  pose 
greater  problems.  We  expect  the  si)ecit  ica¬ 
tion  language  for  the  short  term  tools  to 
support  specir ication  ot  fairness  but  sup¬ 
port  for  verilying  such  properties  may  have 
to  await  the  long  term  tools.  buch  support 
will  probably  involve  enhancement  oi  the 
underlying  logic  with  temporal  constructs. 


honaeterminism  Keq ui rements  tend  to  be 
deterministic  arid  a  nonuetermimstic  pro¬ 
perty  c.  n  usually  be  transformed  to  a  oe ter¬ 
mini  sti  property  by  adding  the  conditions 
under  wl ich  the  property  is  to  bold.  The 
biggest  challenge  p.esentea  by  nonaetermin- 
ism  is  ii:  sjieciiying  ana  verilying  deter¬ 
ministic  transactions  in  the  nonuetermini s- 
tic  environment  or  a  system  oi  concurrent 
processes.  Mechanisms  of  serial izabil ity 
Iron  the  oat.abace  world  seem  appropriate  tor 
dealing  with  tins  problem  ano  we  export  the 
paradigm  ano  tools  or  the  short  term  work¬ 
bench  to  support  these  mechanisms.  The  long 
term  design  may  go  further  in  supporting  the 
mocel  of  sori  al  izabil  ity  as  well  as  particu¬ 
lar  median isms. 

To  the  extent  that  race  conditions  might 
lead  to  unpredictability  where  preaictauil- 
lty  is  needed,  they  need  to  be  avoioeu  by 
use  of  appropriate  concurrency  control 
mechanisms.  At  the  design  level,  it  would 
be  usctul  to  have  support  lor  identifying 
potential  race  conditions. 


Keal-Time  Keq uirpenient-S  Heal  time  require¬ 
ments  oi  uistributea  systems  can  Le  oealt 
with  only  minimally  at  the  r-peci  i  ici'  ti  on 
level.  One  can  introduce  constructs  to 
express  the  time  requi rements.  Verilication 
that  these  requirements  will  be  met  can  only 
L,e  determined  at  a  very  low  level  oi  imple¬ 
mentation.  Thus  it  these  requirements  are 


•?g 


taken  into  account  in  the  tneory  oi  the 
spec  it  j.  ca  Lion  they  have  the  eiiect  oi  intro¬ 
ducing  more  nonaeterminism  and  thus  nega¬ 
tively  impacting  the  veritication  oi  secu- 
r  ity . 


Fault-Tolerance  Keg uirements  Fault  toler¬ 
ance  can  be  designed  into  a  system.  The 
issues  that  need  to  he  consioerec  in  sucn  a 
uesign  are: 


1.  The  failure  model  -  tne  type  ana  amount 
oi  leilures  that  the  design  is  to 
tcler  ate. 

2.  Failure  detection  -  schemes  to  oetect 
failures 

3.  Fault  coni inement  -  limitation  oi  the 
etlect  of  a  lault 

4.  Verification  -  tne  correctness  oi  the 
scheme,  consistency  with  the  specilica- 
tion  mooel ,  assurance  that  the  imple¬ 
mentation  meets  the  reliability 
requirements  oi  the  roilure  model. 


Task  2: _ Datauase  Consi stencv  stuuv 

This  stuoy  was  lea  by  Alejandro  Buchmann  oi 
CCA.  Barbara  blaustein  and  usfien  Chakra- 
varthy  ol  CCA  contributed  to  the  study  as 
Qiu  ban  lialr'ern  and  5am  twre  oi  bytek.  A 
tew  highlights  oi  the  report,  "Latobase  Con¬ 
sistency  and  security"  112]  ioliew. 

The  stuuy  involved  interaction  between  secu¬ 
rity  and  veriLication  at  bytek  anc*  database 
design  at  CCA.  We  discovered  that  at  the 
specitication  level  consistency,  integrity, 
ano  security  can  be  expressed  using  the 
si«ci  t  ica  ti  on  analog  ot  database  con¬ 
straints.  In  another  respect  the  require¬ 
ments  oi  sgeciiying  database  concerns  such 
as  sen  ai  izabil  ity  has  led  to  a  productive 
development  in  our  adaptation  oi  nbM.  Seri¬ 
al  izaoility  is  a  property  involving  the 
oruei  oi  executing  transactions  ami  is  thus 
intrinsically  procedural. 


Jj.yl.ti  level  bpeciii cations  in  the  num  pat  a- 
oigm,  the  place  tor  dealing  with  procedural 
constructs  is  in  the  mappings  between  levels 
ol  a  multilevel  sped  i  i  ca  t  ion.  umor- 
t.unotely,  al  thougii  tiuai  has  an  interesting 
idea  ol  multilevel  specification,  the  con¬ 
cept  ha:,  not  been  woikeo  out  in  sullicicnt 
detail  to  support  the  development  oi  such 
s  jieci  t  i  ca  ii  ons.  '.here  ore  two  lmjx.'r  tant 
issues  in  a  multilevel  specii  i  cation  where 
the  luwer  level  in.pl  erients  the  upier  level. 

1.  The  procedural  risjeets  ot  the  ii.iplemen- 
tatien  nappir.ns  nt-ec  to  tie  expressible 
in  the  (oecl ai ative)  language  oi  the 
lower  level  sjeci  i  ica  ti on  ano 

2.  ':he  presumption  ot  atomicity  as.  regards 
the  upi>er  level  state-changing  o[cmi- 
tione  needs  to  be  justilieu  in  light  or 
its  violation  in  the  lower  level 

spec  it i talion. 


As  port  oi  our  work  in  this  stuuy  we  experi- 
menteo  with  constructs  to  specily  database 
serial  iz  anil  ity  using  a  two  level  specili- 
cation.  We  introduced  the  concept  ol  a 
state  machine  trace  or  history  to  so] ve  1. 
we  lound  that  the  required  j  ustiL  i ca  tion  in 
2  was  similar  to  database  ser  i  al  iz  anil  ity . 

Consi stency  any  secur itv  As  mentioned  ear¬ 
lier,  a  unified  approach  to  database  con¬ 
sistency  ano  security  was  established.  both 
can  be  expressed  in  terms  oi  database  con¬ 
straints.  Thus  security  requirements  can  be 
specified  and  evaluated  with  constraint 
mechanisms  already  available  in  some  data¬ 
base  management  systems. 

We  explored  various  issues  involved  in  the 
me  'tenance  of  consistency  or  a  distributed 
database  in  a  perilous  environment  ano  the 
conflicts  between  concerns  tor  consistency 
anu  concerns  tor  security.  We  proiwsed  the 
concept  ot  flexible  evaluation  of  database 
constraints  as  a  means  oi  addressing  both 
problems.  We  suggest  three  kinds  ot  flexi¬ 
bility:  deterred  evaluation  ol  constraints, 
alternative  actions  in  response  to  a  viola¬ 
tion,  ana  a  more  general  notion  of  a  con¬ 
straint  -  one  which  alleys  lor  exceptions. 

In  the  case  ot  deterred  evaluation  of  con¬ 
straints  some  updates  are  allowed  without 
consistency  checking.  The  new  data  is 
marked  as  unreliable.  At  some  later  time  a 
process  checks  for  consistency  arm  restores 
it  ii  necessary  by  deleting  some  or  all  of 
the  marked  data.  This  approach  could  be  use- 
i ul  in  resolving  conllict  between  the  needs 
ol  security  and  consistency  when  consistency 
constraints  span  security  levels.  The 
potential  llow  ot  information  between  secu¬ 
rity  level:,  would  be  avoiaou  or  reduced  by 
deterring  evaluation  trom  update  time  to 
say  the  end  of  the  day.  The  same  mechanism 
couic  be  useful  in  battle  situations  where 
security  leaks  are  ol  secondary  concern  com¬ 
pared  w  l  tii  real  time  r  eq  ui  rements.  In  this 
case  the  checking  oi  security  constraints 
would  be  uei  or  ted. 


Task  3 _  jriuii  L  Tul  £_r  ance 


■This  task  war.  led  by  Douglas  Weber  ot  OKA. 

A  tew  highlights  of  the  rejiort,  "verifica¬ 
tion  oi  Fault  Tolerance"  U21,  rollow. 

in  this  stuuy  we  were  concerned  with  a 
declarative,  rather  than  procedural,  defini¬ 
tion  oi  lr.ult  tolerance  aria  what  steps  must 
lie  taken  to  prove  that  a  sy stern  design  in 
1  act  lias  sucti  fault  tolerant  projietties. 
bean  time  to  irilure,  a  common  measure  ot 
lault  tolerance,  was  not  appropriate  in  this 
context  sincr  it  oei>cnas  on  the  operating 
environment  ot  tne  system,  not  Lhe  design, 
we  ocalt  lnrteao  with  the  concept  or  "lault 
scenario."  A  lault  scenario  is  a  history  uL 
a  system's  interaction  w i tn  its  environment 
which  includes  not  only  its  inputs  ano  out¬ 
puts.,  but  also  a  description  oi  iriJ  tires.  /. 
system's  environment  will  determine  whether 
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or  not  a  particular  lault  scenario  occurs, 
usually  in  a  random  way.  Thee  el  ore,  a 
system's  environment  "assigns"  probabilities 
to  each  lault  scenario.  bean  time  to 
failure  is  aetormined  by  the  probabilities 
or  lault  scenarios  for  which  the  system  is 
not  "tolerant." 

bur  treatment  or  inult  tolerance  in  this 
stuuy  was  only  minimal ly  concerned  with 
strategies,  designs,  ami  alogoriuiius  used  to 
implement  fault  tolerant  systems,  ano  only 
then  as  examples  to  show  why  a  particular 
definition  ol  1 aul t-t ol er an ce  is  relevant, 
we  consioered  verification  ol  tault  toler¬ 
ance  to  be  a  prooi  that  a  system  design  sup¬ 
ports  a  given  set  ot  lault  scenarios.  We 
have  not  dealt  with  t.ie  problems  ol  insuring 
that  a  system  meets  the  r eq ui rement s  ol  its 
desi  an. 

uur  definition  oi  lault  tolerance  is  similar 
to  the  noninterierence  oeiinition  ot  secu¬ 
rity.  In  essence  it  says  that  the  system 
behavior  in  the  presence  oi  a  given  lault 
scenario  is  the  same  as  the  behavior  in  the 
absence  ol  the  laults  ol  that  scenario, 
where  behavior  is  denned  in  terms  oi  inputs 
and  outputs. 

methods  l or  implementing  lault  tolerant  sys¬ 
tems  are  oilierent  trom  the  access  control 
methods  lor  implementing  security  because 
laults  are  not  external  events  ann  theretoce 
it  is  not  {possible  lor  a  system  to  oecioe 
immediately  whether  they  are  lault  events  or 
not. 

fault  tolerance  is  usually  impl emented  by 
redundancy.  There! ore  one  simple  way  to 
st* city  lault  tolerance  is  to  si* city  the 
redundancy  ol  state  information  in  the 
oesign.  A  design  is  lault  tolerant  ii  it 
correctly  maintains  the  redundancy  as  an 
invariant  even  in  the  presence  ol  the  speci¬ 
fied  laults. 

Our  approach  to  specirying  lault  tolerance 
involves  speciiying  a  set  0  ol  lault 
scenarios.  With  this  approach  it  would  be 
useiul  to  hove  a  way  ol  speciiying  a  orace- 
1  ui  degradation  proj^erty  to  the  enect  that 
lault  scenarios  only  slightly  worse  than 
those  sjiecitieci  will  not  reduce  the  system 
to  chaos.  Gravel ul  degradation  can  be 
del ineo  in  terms  ol  limited  i nten er cnce . 
Then  we  can  use  the  same  approach  to  speci¬ 
iying  graceful  oeyradation  as  to  lault 
tolerance.  A  set  of  laults  C'  that  induces 
the  laults  close  to  those  in  b  is  del  ineo. 

An  appropriate  invariant  lot  C'  will  result 
l rom  a  weakening  or  tne  invariant  lor  G. 

We  e xper imenteo  with  modeling  an  example 
using  HUM.  It  was  possible  to  si>cciiy  a 
particular  redundancy  design  but  it  was  also 
clear  that  more  supper  t.  lor  tne  concept  o). 
history  or  trace  was  called  lor. 


Task  4  txisiiiig  Tools  sdu  Methodologies 
_b!i>  ny 


This  task  is  1  eu  by  ban  hali*rii  of  bytek. 
Ml  members  oi  the  team  are  contributors  to 
the  stuuy.  We  retort  here  mainly  on  work 
cone  at  Sytek. 


£  to  fluid  ipeciiioatiAD  Language  iai  lusLiir 
but eo  systems  tor  the  short  term  tools  we 
expect  to  oevelop  a  distributed  system 
speci f  ica  Lion  language  (DSL)  to  oeaj  with 
the  issues  which  confront  us:  object- 
orienteci  uesign,  concurrency,  ano  hierarchi¬ 
cal  oesign.  we  are  familiar  with  hlif.  as 
eniiariceo  by  tne  huse  tools  17]  sno  with  Vo.:- 
langen  [Id]  and  these  will  serve  as  a  basis 
i  or  our  aev  el  opmerit  of  bsL  . 

Aspects  of  object-oriented  design  ana 
specification  of  concurrency  have  been 
worked  out  in  Veilangen.  We  have  thought 
about  liow  to  nioaily  the  concept,  ol  an  HUM 
mocule  to  be  compatible  with  Verlangen's 
class  and  process  concepts.  Such  an  evolu¬ 
tion  of  hbh  seems  natural  ana  nonprob- 
1  emati  c. 

we  are  experimenting  with  the  hbM  concept  oi 
specification  levels.  hDli  envisages  a 
liier  arcnical  development  where  cacti  level  oi 
trie  hierarchy  represents  a  scute  machine. 

In  the  libri  concept  a  lower  level  machine 
impl  ements  the  next  higher  level,  '.'-he  con¬ 
cept  is  similar  to  what  is  used  in  computer 
and  network  architecture.  Levels  are  to  be 
tied  together  by  implementation  mappings. 
These  mappings  preserve  the  specification 
constructs,  l.e.  types  are  mapped  r.  o  ty(jcs, 
state-variables  to  state  variables,  opera¬ 
tions  to  o]>erations,  etc.  Mappings  l  or 
operations  involve  procedural  constructs; 
all  tne  other  mappings  are  expressed  in  a 
declarative  language.  Typically  the  mapping 
images  of  the  nonprocedural  parts  oi  the 
specification  will  be  characterized  by 
decreasing  levels  of  abstraction.  Theoreti¬ 
cally,  the  lowest  level  of  specification 
v/  il  i  involve  types  and  other  constructs 
which  correr-)X3nti  directly  to  the  ingredients 
ol  tiic  target  higher-order  language  (libL)  . 

If  the  mappings  are  also  expressible  in  the 
h  ul  ,  the  multilevel  specit  ica  tion  could  be 
converted  cirectly  into  cone  in  such  c  way 
that  the  layers  ot  the  sj* cii ica ti on  become 
layers  ol  the  i mpl omenta tion.  In  practice, 
Lias  j>erlect  mapping  from  si* ci 1 1 cation  to 
code  is  unlikely  lor  at  least  three  reasons: 

1.  Kestricting  the  specification  ol  map¬ 
pings  to  impl ementaule  constructs  may 
ne  too  constricting, 

2.  Ihe  spec il ica tion  is  l.kely  to  tollow 
tne  imper atives  oi  formal  si*  cil ica tion 
anu  verification  ano  these  are  not  the 
same  as  the  inger atives  ol  ellicieut 
coue  construction. 

3.  furthermore,  the  tlUi  concept  that  the 
specification  is  conijxiseo  oi  levels 
which  3i e  complete  machines  seems  to  be 
unnecessarily  rigid. 
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i»ev  crthel  ess,  the  .'ptrodutUuii  ol  procedural 
constructs  into  the  spec  it ica Lion  should 
ulUw  Uic  sp-oir  i  call  on  to  get  closer  to  Uie 
cone  level  th a c  il  coul  c  without  such  con¬ 
structs.  Thus  some  i  mj>l  cmentati  on  issues 
can  be  adoresseu  wim  such  spec  ili  cat  ions. 


ijotJiial  Techniques.  ar;<a  boltwai  ^Ljiuineci  in*j 

ui  unciei  pt  and  ana  subscribe  to  the  wiaely 
pel  a  bel  icl.  that  the  economical  oev el opment 
ol  reliable  software  depends  on  a  oevelop- 
nient.  process  which  pays  attention  to  mainte¬ 
nance,  reusability,  and  e/t.enoibil .  y.  we 
believe  t.n  at  oh]  ect -or  i  enter,  ae  i  on  is 
currently  the  best  uosign  par  aolon.  lor  sup¬ 
porting  these  goals  directly.  A  persuasive 
case  is  made  by  bertrana  [leyer  1141  . 

we  also  subscribe  to  the  bei iet  that  reusa¬ 
bility  01  cooe  implies  specification 
reusability  ano  in  turn,  that  this  requires 
formal  specification  of  interlaces.  Thus  we 
see  two  somewhat  Qirrorent  requirements  for 
formality:  those  of  formal  verification  snu 
those  of  tormal  specification  or  interlaces 
to  support  evolution  ol  sol  tw  are.  We  also 
believe  that  formal  veril  ication  pi. ay s  only 
a  small  part  jn  t.he  development.  01  reliable 
systems.  Certainly,  given  the  current  state 
oi  formal  veril  ication,  the  other  putts  ol 
the  development  process  are  more  important 
in  the  sense  that  if  those  are  faulty  the 
verification  can  be  remu*i.ec  useless,  but  it 
these  are  aone  well,  a  faulty  veril ication 
will  not  oegrade  their  impact,  ine  result 
oi  these  belieit  is  a  commitment  to  pay  muen 
attention  to  software  engineering  not  only 
tor  the  usual  reasons,  but  also  as  an 
integral  adjunct  ot  formal  verification  anu 
as  a  process  that  can  benefit  directly  from 
formal  methods. 

‘■Therefore,  in  tnis,  task,  besides  reviewing 
existing  verification  systems  such  as  Oypsy 
[lh]  ,  hU-i-Muso,  t'bi-i  llvl  ,  anu  Ver)  ancon  ario 
specification  paradigms  such  as  Cbl.  i  1 7.1  we 
ate  exploring  oitierent  aspects  ot  software 
engineering.  OKA  is  looking  at  Aua  support 
environments.  CCA  is  investigating  bbku 
design  systems.  KCA  is  looking  at  coni j- 
guration  management. 

by tek  is  involved  in  a  survey  oi  software 
engineering  environments.  Mny  of  the  tools 
we  have  investigated  concentrate  or,  nit  ecu 
support  tot  the  development  ol  coo?.  The 
production  ol  spr.  ell  ica  Lion  is  only  inciden¬ 
tal  to  coue  development.,  we  neeu  a  pon  aui.gm 
which  emphasizes  the  sic cit ica tion  as  t- r,  erm 
proouct.  and  preferably  one  that  permits  3 
gr actual  hierarchical  development  i  wm. 
spec,  it  ica  tion  to  core.  Liitei  lit) 
oevelO|)ecl  by  Interactive  Software  hnqinf-.ei - 
ing  ol  Santa  Barbara  appears  to  be  an  ideal 
choice.  It  achieves  the  ciesirec;  development 
goals  by  supporting  a  rich  version  of  object 
oriented  design  ana  progi amming.  Further¬ 
more,  it  achieves  a  crucial  form  of  flexi¬ 
bility  in  that  it  has  a  form  ol  target 
language?  inde[x?nocnce.  The  system  can 
accommodate  any  programming  language  that 
can  be  calico  trom  t.  Thus  an  Liitei 
si>ecit  ication/progr  am  has  an  interest  ing 


82 


reusability  feature  -  namely  it  can  Liu 
reused  v'itn  oitroicr.t  oegreos  of  complete¬ 
ness.  11  one  needs  or  wants  to  one  a  oil¬ 
ier  on*.  pi  our  amm  my  language-  out  likes  the 
spec  n  ica  tion  ano  structure  oi  an  Lift  el 
program,  it  is  crjy  necessary  to  rewrite  the 
lew  level  code  in  the  new  language.  The  new 
impl  ementLM  j  on  will  have  the  same  runt  ime 
anti  testing  support  itom  till  cl  as  ciin  the 
original.  Thus  lift'd  can  bo  used  as  a  Hji.. 
lot  Aaa  progi sms. 

This  kino  of  partial  reusability  appears  to 
otter  greater  promise  than  a  more  rigid  torm 
o).  reuaamljty.  one  obvious  limitation  on 
reusability  of  coue  is  the  multitude  oi  pro¬ 
gramming  languages.  Although  this  proli- 
letation  ir.  oecried  by  some  and  attempts 
have  been  made  to  er.tor  e  a  standard  such  as 
Aaa,  there  is  good  reason  to  believe  that 
programming  languages,  like  natural 
languages,  are  destined  to  be  with  us  in 
abundance.  The  titl'd  paradigm  attemjrf.s  to 
live  with  this  reality  and  in  so  doing 
otters  possi Si]  ities  ot  more  success  than 
paradigms  which  assume  that  reality  will 
cn an go  to  accommodate  thorn. 

for  us,  Lift  el  suggests  an  intriguing  direc¬ 
tion  lor  the  scenario  outlined  above.  Our 
development  ot  b.TL  will  involve  numerous 
design  choices  concerning  such  things  as 
multiple  inheritance,  generic  typer-, 
pel yn e.rphic  tyjoig  epa  sialic  tyi.v  checking, 
These  cnoices  have  ain.-cu.iy  been  resolved  in 
the  design  of  i.ilfel.  Furthermore,  biifel 
contains  the  rudiments  ot  formed  specifica¬ 
tion  and  a  paiacigm  that  uses  inheritance  to 
support  hierarchical  development  from 
.speciticatj  on  to  code.  To  the  extent  that 
we  can  abiae  by  the  decisions  rnaue  in  tii- 
rel  ,  our  language  could  eventually  be  incor¬ 
porated  into  tiff  cl  as  an  enhancement..  ut 
course,  things  ate  not  likely  to  go  so 
smootnly  so  a  combined  system,  un\,  ana  hit- 
tel,  is  lixely  to  involve  changes  to  bit  tel 
as  well.  Never  tholes.*:,  it  the  marriage  goes 
well,  we  will  have  a  .short  teiin  workbench 
and  perhaps  r>  .long  tern;  design  tat  more 
valuable  than  we  her;  a  right  to  expect  when 
we  wrote  our  proposal  in  April  oi  Is  bo. 
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Underlying  this  project  is  the  L-v-uiei  that 
an  e.iv  i  roiumnt  lor  developing  secure  c-istr  i- 
b  uteri  systems  which  incluues  both  formal 
methods  ano  traditional  software  engineering 
can  be  uevelope-o.  Ad  though  the  belief  is 
still.  lar  iron;  vinuicateo,  our  initial  work 
supports  optimism  in  this  regard.  l-dithcr- 
i.-oi e,  it  that  the  attempt  at.  this 

type  oi  development  in  the  context  or 
acini  or.sing  the  net-os  ot  secure  distributee, 
systems  can  have  a  beneficial  impact  on  the 
star  e- ol -the-ait  in  tormal  sp.-ci  i  ica  ti  on. 
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SPECIFICATION  I  OK  A  CANONICAL  CONFIGURATION  ACCOUNTING  1 OOL 


K  I  A-'oiKii  d  Ki  own 
Computet  Security  Cilice.  Ml/055 
i  he  Aerospace  Cor  (rotation 
P.O.  Box  97.957 
Los  Angeles,  CA  90009 


The  Trusted  Computer  System  evaluation  Criteria 1  includes  the  requnement  that 
design  documentation  and  source  axle  of  a  B2  or  higher  cla.»s  compntei  system  be 
kept  under  configuration  management  during  development  and  maintenance  of  the 
system.  Furthermore,  new  releases  ol  evaluated  systems  that  are  submitted  to  the 
National  Computer  Security  Center  (NCSC)  for  ic-cvaluation  as  the  same  class 
f  maintenance  of  ratings  evaluation)  must  have  been  kept  under  configuration 
control  since  the  previous  evaluation.  As  an  aid  to  evaluation  of  other 
configuration  accounting  systems  for  use  in  development  of  a  secure  system,  a 
canonical  Text  and  Code  Control  System  (TCCS)  has  been  defined.  This  paper 
describes  the  system.  This  system  is  not  intended  to  be  built,  since  it  is  not  fully 
defined  hem  or  in  the  draft  guideline,  nor  does  it  have  all  the  functionality  of  some 
existing  systems.  Rather,  the  TCCS  is  presented  as  a  reference  standard  that  a 
product  that  is  under  consideration  tor  development  or  purchase  can  lx:  compared 
against.  The  use  of  TCCS,  or  a  similar  tool,  as  an  integral  part  of  the  software 
development  cycle  is  deset  ibed. 

1.  Introduction 

The  Aerospace  Corporation  has  prepared  a  draft  guideline2  on  configuration 
management  tor  operating  system  software  and  computer  hardware  that  desenbex 
the  minimum  configuration  management  effort  required  at  the  B2,  B3  and  A1 
cl.i.v'C.’  of  the  Trusted  Computer  System  Cv. dilation  Crilerii j1.  This  guideline  also 
recommends  higher  levels  of  effort  tor  all  systems  submitted  to  the  NCSC  tor 
evaluation.  As  part  ol  the  rcsca'vh  conducted  during  preparation  of  the  draft 
guideline,  several  existing  automated  conligutation  accounting  systems  were 
examined.  Two  were  found  to  be  in  common  use  and  also  sufficient  for  the 
recommended  level  of  configuration  accounting.  These  were  the  Source  Code 
Control  System  (SCCS)  which  runs  under  the  Unix*  operating  system,  and  die 
VAX  DHC/CMS  (Code  Management  System)**online  library  system,  which  runs 
under  die  Digital  equipment  Corporation  VMS  operating  system.  Both  require 
the  use  of  additional  programs,  make  in  the  case  ol  SCCS  and  VAX  DTC/MMS 
(Module  Management  System)  in  the  case  of  ('MS. 

Major  tealures  of  these  utilities  are  incorporated  into  the  specification  of  TCCS. 
TCCS  is  intended  as  a  reference  standard  against  winch  one  can  compare 
prospective  configuration  accounting  tools  It  one  can  perform  the  same 
operations  as  are  performed  by  a  function  in  TCCS  by  using  at  most  a  few  basic 
functions  ot  the  projxised  system,  and  it  the  database  entiics  contain 
approximately  the  same  information  that  a  TCCS  dncctory  and  its  Ides  coni j in, 
then  that  system  would  allow  an  appropriate  level  of  configuration  management  to 
be  applied  to  development  of  a  secure  computer  system. 

1.1  ( tigani/ation  ot  Paper 

The  pajvi  consists  of  the  following  sections  Section  2  describes  the  functionality 
or  SCCS  with  make,  and  then  (hat  ol  VAX  1)1  ("/(’MS  with  DhOMMS.  A 
recommended  feature  that  neither  system  hk  hides  is  described  a*,  the  end  ol 
sect uui  2  Section  3  has  two  subsections  ‘I  he  t»si  describes  the  syntax  and 
functionality  of  die  bask  calls  of  'I  CCS  I  he  second  goes  implemem.it ■  •<  notes 
tor  the  system  Again,  this  is  not  because  it  is  intended  that  "1CCS  h 
implemented,  but  it  a  product  is  being  evaluated  for  use  with  a  paitk  lai 
development  m.ichne  and  its  operating  system,  one  would  have  to  hypothesize 
how  TCCS  would  be  implemented  on  that  machine  and  operating  system  m  order 
to  compaie  it  to  the  product  being  evaluated  Set  non  4  describes 
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how  TCCS  would  be  used  during  the  development  of  a  project  which  was  subject 
to  die  requiicments  ot  IX)L)-ST1)-2I(»7\  Defense  System  Software  Development. 
This  does  not  mean  that  the  NCSC  will  require  that  secure  computer  systems  be 
developed  to  this  government  standard,  but  this  standard  is  well  known  and  is 
similar  to  the  software  development  cycle  used  by  many  vendors.  The  Appendix 
contains  the  Backus  Naur  Form  for  the  simple  grammar  of  TCCS;  these  calls 
would  typically  invoke  a  particular  interactive  function  which  would  then  prompt 
die  user  for  the  information  requited  to  complete  the  operation.  On  some  systems, 
a  command  processor  would  have  to  be  invoked  tiist;  on  oilier  sy  stems,  the 
functions  could  be  called  from  the  top  level  command  interpreter.  The  intent  of 
including  the  syntax  specification  is  to  show  what  parts  of  an  instance  of  TCCS 
are  dependent  on  its  implementation  and  which  depend  on  the  opcialing  system. 

2.  Hxistmg  systems 

A  number  of  software  developers  have  created  the  kind  of  «miom  *ed  document 
control  facility  that  piojicr  configuration  accounting  requires.  Text,  both  horn 
source  code  and  from  the  other  documents  involved  in  the  development  ot 
software  and  hardware,  can  be  entered  and  modified  only  through  use  ot  the 
automated  system,  although  any  programmer  can  get  a  working  copy  of  the 
current  developmental  configuration  for  purposes  of  modifying  the  source  code  or 
documentation,  or  testing  the  latest  vers  ton  of  the  software.  Updating  the  source 
code  or  document  must  be  done  only  by  jvisonnel  with  permission  to  make  such 
updates.  The  examples  discussed  below  aie  partially  dependent  on  the 
discretionary  access  control  mechanisms  ot  then  existing  system,  but  each  system 
records  who  made  each  upda'e;  in  addition,  a  reason  for  update  may  be  asked  for. 
In  addition  to  the  existing  systems  described  here,  most  commercial  database 
management  systems  (DBMS)  can  be  used  lor  configuration  accounting  by 
creating  a  front  end  processor  that  interfaces  to  the  query  language  processor  of 
the  DBMS.  If  a  DBMS  is  used,  then  it  must  have  only  read  or  write  access  io  die 
records,  and  all  updates  must  be  made  through  its  quay  language. 

To  motivate  the  list  of  general  functions  given  below  in  section  3.1,  a  description 
of  two  similar  systems  is  given  here.  Under  the  Hnu,M  system,  the  make  utility, 
and  the  elements  admin,  grt.prs  and  delta  which  comprise  tire  Source  Code 
Control  System  provide  a  basic  coutigmahon  accounting  system.  The  Module 
Management  System  (VAX  DFC/MMS)  and  Code  Management  System  (VAX 
DF.OCMS)  winch  run  under  the  Dl  C  VMS  operating  system  provides  similar 
facilities.  In  fact,  MMS  rv  modeled  atiei  make  and  has  an  almost  identical  syntax. 

2.1  Unix'1*1  SCCS 

The  SCCS  system  nnrs  under  the  Unix lM  operating  system  There  are  several 
good  references  on  it,  including  an  overview4  and  a  manual**.  The  steps  of 
configuration  accounting  coi responding  to  the  life  c>cle  step1*  described  in  I  KM) 
ST  1>  ?lh7  require  a  sene'  of  function  calls  from  the  operating  system  shelf 
Iiuti.ill)  a  directory  is  created  using  the  mkiUr  function  At  this  point,  it  is  possible 
to  use  (he  owner,  group,  world  pioicYiion  scheme  provided  by  Umx,M  to  protect 
the  directory  In  addition,  a  list  of  login  identifiers  is  created  to  specify  who  may 
update  eac  h  element  to  be  processed  h\  SCCS  Some  protection  strategies  arc 
discussed  below 

1  or  not.ition.d  purposes,  c.kh  entry  in  i lie  directory  is  referred  to  as  an  element. 
Following  due*. lory  initiation,  each  dosinnent  is  entered  initially  using  ihe 
fulktion  admm  n  (the  -n  modifier  specifics  ibis  j\  ,i  new  elemeni)  As  e.iuh 
update  is  made  to  an  element,  a  new  genc..iiu>n  ot  that  element  is  created  S(  (  S 
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calls  each  new  generation  a  della.  V,.ch  clcni*:»:t  ’.*•  stored  in  a  file  by  SCCS,  and 
the  filename  is  prefixed  by  s.;  any  added  to  the  dirc<  mry  that  di-  n^t  meet  tnir 
requirement  are  ignored  by  the  SCCS  turn  fi  m  calls,  A  number  of  arguments  may 
be  specified  when  admit:  .s  called,  Thes;  a-guments  speedy  parameters  that 
alfect  the  file,  and  may  be  changed  by  3  subsequent  call  to  adnaK  For  example, 
one  such  parameter  indicates  whether  bianche*.  be  no;  a  cl  for  an  element 
The  idogm  argument  is  used  to  create  the  equivalent  ol  access  vontiol  ,i  -t  by 
listing  login  names  of  use  is  who  can  apply  the  delta  function  to  the  eU.iiu.-nt,  thus 
Creating  citlict  a  new  generation  (d  ;IM)  or  a  varian  branch.  Scipn^  rbc  v  flag 
causes  a  prompt  tor  MR  (Modification  Request)  iiumbeis  to  he  issued  on  any 
ujKiitc.  The  admin  function  is  also  used  to  change  any  flags  or  paramet  ’o. 

During  the  initial  writing  of  source  code,  the  programmer  Keeps  the  code  in  his 
own  directory  until  it  will  compile  and  pn.v.  a  fesv  simple  unit  tests.  The  initial 
release,  or  initial  delta,  of  each  code  module  is  inserted  into  the  SCCS  'Ltoqo'y  'ey 
means  of  the  admin  -n  function.  The  programmer  may  updi.tr  each  such  'nodule 
by  using  the  get  -c  function  which  indicates  that  the  module  will  be  edited,  and 
then  the  completed  document  will  be  reentered  into  the  directory  using  the  delta 
function.  As  long  as  tlte  module  being  edited  was  exti acted  from  the  SCCS 
directory  using  get  -r,  it  can  be  returned  to  the  libiary  using  delta,  and  all 
necessary  update  information  will  be  entered  with  it,  including  the  MR  number  it 
admin  -fv  has  been  called  to  set  the  v  flag.  The  get  function  can  be  used  to  extract 
a  copy  of  any  document,  hut  after  it  is  edited  it  cannot  be  reentered  »nto  the 
directory.  Get  is  useful  for  priming  out  copies  of  documents,  tunning  test 
compilations  when  some  other  module  is  being  modified,  or  to  allow  more  than 
one  team  member  to  work  on  die  same  document  since  the  project  managci  can 
then  use  g et  ~c  and  delta  to  enter  the  final,  approved  changes. 

When  the  code  is  to  be  tested,  moke  can  be  used  to  generate  a  test  build.  This 
function  looks  for  a  file  named  makefdr  in  the  current  drrectoiy  and  ln«.s  to  cic«tc 
a  new  version  of  the  file  named  on  the  Inst  line.  Since  this  rs  usually  an 
executable  file,  it  checks  to  see  whether  all  the  object  files  needed  by  the  loader  to 
create  this  executable  file  are  up  to  date,  which  is  only  true  if  the  source  files  arc 
up  to  dale.  In  other  words,  the  makefile  gives  the  dependencies  of  an  executable 
file,  and  nukes  suie  the  hist  moditied  date  of  any  file  is  the  same  or  earlier  than 
that  of  :ny  file  that  depen/s  on  it.  When  such  is  not  the  case,  the  contents  of 
makefile  specifies  what  action  to  take,  or  if  no  action  is  listed,  searches  a  list  of 
default  actions,  For  example,  if  kernel.o,  an  object  file,  must  be  updated  because 
kernel.c  is  newer,  then  make  will  automatically  run  the  C  language  compiler  on 
kernel.c.  If  the  source  files  ate  kept  in  the  SCCS  directory,  then  make  must  get 
the  needed  source  flies  from  there.  A  .Pl.lAULT  entry  in  the  make  file  can  be 
used  to  apply  get  to  all  needed  source  files  if  any  of  the  object  files  require 
updating. 

Another  concept  that  i>  useful  ir»  integrating  and  testing  software  is  that  of  the 
software  build.  During  the  testing  phase  ol  software  development,  a  subsystem  of 
mod..’es  can  be  integrated  into  a  single  executable  load  module  and  tested 
However,  while  this  testing  goes  on  some  of  the  source  files  may  still  be  under 
development.  Testing  a  software  budd  requires  a  stable  set  of  files.  SCCS  ai  d 
make  can  handle  this  in  one  of  two  ways:  cutoff  specification  and  branching.  If  no 
source  lilcs  will  be  modified  dunng  the  testing,  even  to  correct  minor  syntactic 
errors,  then  the  makefile  that  creates  the  build  can  specify  on  the  get  function  that 
only  deltas  made  by  the  testing  start  date  ^re  to  be  included.  Thus,  the  same 
versions  of  the  source  code  are  always  retrieved  Alternatively,  it  some  minor 
debugging  will  be  allowed  during  the  testing,  while  the  development  team 
continues  to  work  on  the  source  code  so  it  will  interact  correctly  with  a  later  test 
build,  then  each  element  of  die  source  ct>du  can  be  spin  irv  two  or  more 
bianches  One  branch  will  only  contain  the  niinoi  debugging  changes  made  by 
the  testing  team,  while  the  other  bunch  will  contain  changes  nude  by  lire 
development  team.  When  testing  is  finished,  all  changes  made  dunng  testing 
must  be  incorporated  with  the  current  developnic.it  team  code. 
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SCCS  prc./cies  *SiC  capability  m  spicily  a  soltwav  build  by  the  way  it  assies  an 
SCC*  Identification  number  (SIP)  to  each,  ouinu  u*  the  </r.'n>  f auction.  Then  sure 
get  any  version  of text  01  soince  code  f»lc  by  specifying  the  appi  ipnate  SID. 
The  torm  of  the  rdvr.tdier  is  R.L|.H| -Sp  wbcic  each  ot  Rt  l„  I)  and  S  is  an  integer . 
R  stand-,  loi  the  Release  numhci,  v  l  ull  is  initially  1  and  iiast  be  foiced  to 
increment  by  a  specific  i«vv  acuoii.  I  stands  for  Release  Level.  The  project 
manager  may  decide  to  allow  several  branches  to  be  v  icatcd  within  the  same  tile, 
either  with  the  ini*;n:  ol  latei  incorjxiialiiig  ii»;*ve  branches  into  the  same 
document,  c*  o!  having  a  different  b'anch  tor  each  possible  haidwaie 
ccrutgmaiion,  oi  each  possible  subset  of  peripheral  devices,  or  toi  soure  other 
reason.  In  that  case,  the  optional  Li  stands  f-oi  lire  Oianeli  designator  and.  lui  eacli 
btanch,  the  S  stands  tor  tbe  sequence  laiaibei.  Suaighiturwaid  iuIcs  dclme  how 
to  spi\  iry  tUn  pauiculai  SID  desirco  when  get  is  called.  II  .o  SID  is  specilied 
then  die  latest  release  and  level  is  provided.  A  biet-ch  must  be  explicitly  named  as 
an  argument  lo  get  for  it  to  be  retrieved.  Tlic  SID  ol  the  resulting  call  to  delta  ir 
also  affected  by  the  SlP  used  when  g-'l  -c  is  called.  A  table  showing  the  e  rules  is 
provided  in  tin;  description  of  die  get  function  in  the  i’ru:  ‘*{  programmer's 

Two  versions  may  be  incorporated  using  the  get  r  bxt  <vn»'ti*in.  specifying  the 
most  recent  sequence  numhci  ol  each  branch.  1 1  c  user  who  executes  this  will  be 
notified  ot  any  conflicting  modifications  and  must  handle  these  interactively. 

lire  function />r.v  allows  for  coufiguiaiion  audit,  since  it  extracts  information  tmm 
the  s.  files  in  the  SCCS  directory  and  prints  them.  /7a  can  be  used  to  quickly 
create  reports  which  list  one  ot  two  impoitant  values,  such  as  last  modified  date, 
for  many  S CCS  tiles,  or  many  values  lor  one  or  two  files.  Larger  reports  van  also 
be  created  and  processed  using  an  editor. 

2.1  VAX  P  TOC  MS  and  Dl  C/MMS 

The  cont liquation  accounting  system  called  V  AX  PUOCMS6  is  also  used  to  track 
a  history  of  each  text  file  stored  :n  a  CMS  directory,  but  CMS  does  significantly 
more  auditing  and  cross  checking  than  SCCS  does,  l  or  example,  it  an  editor  is 
used  directly  to  modify  a  file  in  a  CMS  directory,  any  further  use  of  that  hie  by 
CMS  generates  a  warning  message.  Any  files  entered  into  a  CMS  directory  by- 
other  than  tbe  CMS  utility  will  cause  CMS  itself  to  issue  a  warning  message  when 
it  is  invoked  for  that  directory.  Otherwise,  the  process  of  configuration 
accounting  is  similar  to  that  used  with  SCCS. 

The  CMS  CRLATL  1  IHR  ARY  function  causes  a  directory  to  be  set  up.  and  initial 
logging  to  start.  The  project  manager  enters  each  clement  into  the  directory  by 
using  the  CMS  CRFAYb.  Ll.hMl.NT  function.  One  must  Rl  SI  RV|.  an  element 
of  a  library  to  modify  it,  and  it  can  he  put  back  into  the  library  only  by  using  the 
RLPLACT*  function.  If  someone  else  has  Rl.Sli.RVLd  an  element  between  the 
original  programmer’s  RLSKRVL  and  Rl  W  ACL  calls,  a  warning  is  issued  lo 
both  programmers  and  the  occurrence  is  logged.  To  get  a  sample  copy  ol  text, 
such  as  a  program  source,  the  H.TCH  function  will  generate  the  latest  generation, 
or  any  specified  generation,  of  an  element,  but  will  not  allow  a  modified  copy  to 
be  reinserted  into  the  library.  Inc  SHOW  function  can  be  used  to  audit  the 
information  about  each  element  m  the  library. 

MMS  is  almost  identical  to  wn.-Ao.  even  down  to  using  the  default  name  m,ikejilr 
if  its  first  default  description  file  PLSCK1I*  MMS  re  not  m  the  current  directory 

Differences  between  SCCS  and  Pl.C-C  MS  apjvai  concerning  software’  builds  In 
l'mx1M  a  build  must  be  cithci  described  m  a  makejde.  or  else  each  element  to  be 
used  m  a  build  mud  be  retrieved  from  the  SCCS  directory  using  get.  placed  in 
another  directory,  and  the  makejde  then  may  refer  to  these  souree  tiles  to  create 
the  executable  build  In  CMS.  the  process  ot  selecting  only  a  subset  ot  source 
files,  including  sonic  which  ate  not  the  most  current,  re  automated  by  the  use  of 
lire  class  and  group  mechanisms  1  <»  see  how  this  w orks.  one  niusi  understand  the 
CMS  Loiiecpls  of  generations  and  variants  bach  generation  of  a  file  corresponds 


to  a  I  Jinx'* M  dcliti.  Generations  aic  normally  iiumhcicd  in  ascending  older-  CMS 
also  has  die  capability  of  cicjfing  a  van, nit  development  line  10  any  generation  by 
spa  ifynig  in  the  Kl.ELACE.  function  a  vamnt  name.  I  or  example,  it  one 
RESl  -.UVJ-’s  generation  3  ol  an  element,  then  pet  onus  a 
REPLACED  VARlAN  l'-T,  tins  will  cicate  geneiation  3T1  which  may  then  be 
developed  sepai aiely  horn  gciuMatinn  3.  The  tiist  tune  this  is  used,  the  equivalent 
of  an  SCCS  bianch  delta  is  cicated.  Blanches  themselves  can  have  blanches,  a 
capability  that  SCCS  does  not  have. 

A  group  can  be  defined  within  a  CMS  directory,  using  the  CMS  CREATE. 

GROUP  and  CMS  INSERT  ELEMENT  functions.  A  group  is  composed  of  all 
generations,  including  variant  genciaiions,  of  all  elements  inserted  into  the  group. 
Groups  can  be  included  within  other  groups.  Groups  can  be  defined  with  a 
non  empty  imerseciion  so  that  they  have  overlapping  membership.  The 
DESCRIPTION  file  used  by  MMS  can  specify  the  gioupname  in  a  CMS  1-ETCH 
function  on  the  action  line  of  a  dependency  rule.  This  would  then  fetch  the  most 
recent  generation  of  cadi  member  of  group,  including  a!!  variants.  This  is  not 
all  that  useful  during  development  snue.  as  was  mentioned  above,  the  most  recent 
generation  may  be  changed  by  the  development  team  dunng  the  course  of  testing 
a  build.  I  lowever.  once  all  variants  are  removed  and  the  CMS  library  has 
stabilized,  a  CMS  FETCH  function  oil  a  group  name  might  be  useful. 

A  more  interesting  case  is  the  CMS  class,  which  consists  of  specified  generations 
of  sonic  subset  of  elements.  The  CMS  CREATE  CLASS  function,  logo1  her  with 
the  CMS  INSERT  GENERATION  function  can  be  used  to  specify  the  exact 
elements  of  a  software  build,  and  the  DFSCR 1PTION  file  can  then  refer  to  the 
entire  class  by  using  the  /GENERATION -Iclassname]  qualifier  on  either  the 
source  or  action  line  of  a  dependency  rule.  1  his  makes  the  dependency 
description  files  quite  simple  when  using  MMS  with  CMS  since  the  build  can  be 
defined  within  the  CMS  directory  and  controlled  by  the  program  manager  or 
quality  assurance  team.  1  he  makefile  reqniied  by  Unix  SCCS  can  be  much  moie 
complex  when  it  is  required  to  describe  a  software  build  for  intermediate  testing. 

?  3  The  Bind  Concept 

One  thing  that  SCCS  and  DEC/CMS  lack  is  a  way  to  enforce  that  a  change  to  one 
part  of  the  library  requires  a  change  to  otliei  elements.  For  example,  if  approval  is 
received  to  change  the  algorithm  which  implement*,  a  particular  function, 
including  a  change  in  the  code,  more  than  just  the  code  element  itself  must  be 
changed.  Since  no  change  ha>  beer,  nude  in  the  functional  requirements  of  the 
system,  the  top  level  documents  need  not  be  changed.  But  the  code  element,  the 
lop  level  Design  entries,  any  intermediate  entries  involving  a  description  of  how 
the  system  functional  specifications  are  met  by  software,  any  documents  that 
address  how  the  system  functions  inter  'tally,  and  especially  the  test  documentation 
and  test  code  itself  must  be  changed.  In  existing  software  lifecycle  models  this 
requirement  is  met  by  mapping  each  major  function  of  the  system  down  to  each 
lower  level  in  the  top  down  development  nf  the  system  TTiis  can  be  done 
manually,  hut  could  be  iniotporared  into  the  configuration  accounting  system  as  a 
series  of  finks  between  elements;  change  in  one  element  would  not  only  prompt 
for  the  change  authorization  number  that  required  the  change,  but  would  then  lead 
the  manager  or  librarian  who  is  making  the  changes  to  update  every  higher  and 
lower  level  document,  prompting  fo:  the  authorization  number  any  time  the 
element  is  accessed  until  a  response  is  incorporated  into  the  element  Current 
system  can  do  this  only  by  adding  comments  to  elements  that  are  intended  to 
remind  the  manager  or  hbraiian  to  make  the  responses. 

3.  A  Canonical  System 

The  / C  SIX’  requirements  and  the  sundard  texts  in  software  configuijtion 
management"- v  describe  the  functions  that  an  automated  configuration  accounting 
system  should  provide.  Inspection  of  the  two  popular  systems  described  m  the 
previous  section  suggests  a  wotkjhle  syntax  for  an  interactive  system  These 
features  could  be  implemented  as  p.m  of  j  new  operating  system  under 
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development,  or  through  macros  in  a  DBMS  running  on  the  development  system. 
It  the  development  stall  is  constricting  buying  a  system  for  configuration 
accounting,  this  provides  a  checklist  ot  functions  to  look  for. 

3.1  1  CCS  Functional  Specification 

The  functions  ol  the  Text  and  Code  Control  System  (1  CCS),  and  their  SCCS  and 
CMS  equivalents,  mv  summarized  in  Table  1.  A  more  complete  description  of 
each  function  is  given  below.  The  function  name  >s  in  bold  type,  and  arguments 
ate  in  italics.  No  control  arguments  are  specified,  both  because  different  systems 
implement  these  using  different  syntax  styles,  and  because  the  basic  TCCS  system 
desenbed  here  is  a  minimal  system,  sufficient  tor  conligui abort  accounting  but 
with  no  added  functionality.  However,  if  1  CCS  were  actually  implemented, 
considerations  of  efficiency  and  portability  might  require  additional  aigumcnts. 

•  setup  directory -  CicalO  a  directory,  or  its  equivalent  in  the 
current  operating  system  environment,  including  access  control 
information.  The  initial  access  control  should  be  set  with  only  read 
access  to  the  project  manager,  or  the  entire  group  if  the  operating 
system  allows  for  the  group  concept.  Only  the  TCCS  kernel  should 
have  direct  write  access  to  the  files.  The  creator  of  the  ditectory,  and 
those  team  members  whose  names  appear  on  the  access  control  list 
within  each  clemeni,  should  be  allowed  to  use  the  save  function. 

•  enter  element  filename  *  Move  an  existing  file  into  the  configuration 
accounting  directory  as  the  initial  text  of  a  document,  source  code,  or 
binary  data  element.  Initially  only  the  program  manager  would  have 
save  capability  to  the  file.  The  enter  function  should  prompt  for  'he 
user  identification  of  all  team  members  who  will  also  have  save 
capability.  It  the  operating  system  does  nor  have  a  gioup  mechanism, 
then  enter  should  also  prompt  for  all  users  who  have  read  (actually 
copy)  access  The  enter  function  may  be  reused  without  the  filename 
argument  to  update  this  imoi  mution. 

•  edit  element  specifier  filename  -  Retrieve  a  copy  of  the  specified 
version  of  the  element,  and  place  it  in  a  file  of  the  same  name  in  the 
user’s  current  directory  for  editing.  The  default  when  only  the 
element  name  is  specified  is  the  latest  version  of  an  element.  One 
may  also  specify  an  eailier  version  or  a  branch  version.  The  syntax  of 
an  earlier  or  branch  version  depends  on  the  naming  convention  used 
by  the  save  function  It  more  than  one  editor  is  available  on  the 
system,  this  should  act  as  a  sort  of  preprocessor  which  reconstructs 
the  desired  version  without  any  of  the  TCCS  header  material 
normally  stored  with  it. 

•  save  tut  i  t jrlcments  -  save  the  file  that  was  extracted  with  the  edit 
function  back  into  the  TCCS  directory.  If  list_oJ  elements  is  a  single 
element  name,  then  save  should  inform  the  user  of  the  version 
number  to  be  given  to  the  new  version  and  thru  prompt  foi  any 
modification  to  that  default.  1  his  is  how  a  new  branch  would  be 
initiated  If  list  of  elements  is  a  particular  vcision  specifier,  save 
will  determine  that  it  does  not  already  exist,  and  that  it  is  a  valid 
descendant  of  the  clemeni  nanvd  in  the  corresponding  edit  function, 
and  assign  (ha:  version  specifier  to  the  new  version.  If  two  or  more 
branches  are  to  be  merged,  then  all  versions  of  clement  are*  specified 
in  list  of _el(ments,  all  changes  front  the  latest  common  root  version 
are  applied,  and  any  contradictions  are  signaled  to  the  user  If  the  list 
contains  version  specifiers  that  do  not  arise  from  die  sanic  element, 
then  an  error  condition  is  signalled  and  no  other  action  is  taken 

•  copy  element speiijier  *  create  a  printable  or  compilable  file,  based 
on  the  specified  version  of  element,  which  dues  not  have  sufficient 
inhumation  to  be  edited  and  reen'ered  into  the  library. 

•  audit  element  list  -  The  project  mjnjger,  oi  anyone  with  read 

pi  iv  ilege  to  the  TCCS  director) .  can  direct  information  about  the 
elements  specified  to  be  written  as  a  report  to  the  terminal,  a  standard 
output  device,  or  a  file  The  element  list  can  be  a  huildnume  or 
hmdr.ame.  The  audit  function  prompts  the  user  for  the  information 
required  and  uses  a  default  format  for  the  output.  One  useful  report 


would  be  the  list  of  elements  specified  in  the  buiUtruimc  or  Inndname. 

The  format  can  be  dependent  on  the  output  device .  If  sent  to  a  tile, 
the  icpoit  can  be  piocesscd  with  a  woid  pmccssoi  or  lot  natter. 

There  should  be  a  default  loimat.  easily  specified  by  the  user,  which 
will  produce  a  repoit  in  the  same  for  in  as  that  produced  by  generate 
(see  below).  This  will  allow  the  system  to  meet  the  ICS IX ' 
requirement  for  an  automated  tool  lor  comp. imp  a  newly  generated 
vcision  with  a  previous  veision  ol  the  system 

•  build  huiltinamc  -  specify  a  subset  ot  versions  of  elements  that  can 
then  be  named  with  a  single  buildoame.  The  desciipiivc  information 
is  kept  within  the  TCCS  directory,  rather  than  externally. 

•  link  bindname  -  create  a  list  of  elements  which  all  must  be  changed, 
or  at  least  annotated,  whenever  one  element  is  chanped.  In  a  top 
down,  tree  stiucuncd  development,  this  is  the  equivalent  ot  a  subtiec 
of  the  code  structure.  This  is  in  contract  to  a  build,  winch  is  a 
snapshot  of  a  subset  of  nodes,  none  of  which  is  a  descendant  ot  any 
other,  at  a  partieulai  point  in  the  development  cycle.  Also,  a  bind 
includes  the  corresponding  subtree  ot  the  dr \*u mentation  bee:  design 
documents.  tiny  rcKucii  C  M  plan  d<  h.'  u  itHMtt  ( s) ,  user  ot  u i .11  n Il'ikch  c 
niamial  entries,  test  divumcnts  such  as  luncmiiial  amt  acceptance  lest 
plans.  It  should  also  include  the  test  code  itself.  At  a  minimum  one 
Inndname  tile  designates  tlie  entile  development  nee  should  be 
identified.  Subsidiary  hinds  could  be  identified  for  various  subgioups 
of  the  development  team,  or  for  test  builds,  or  lor  valiant  versions  that 
ate  dependent  on  different  hardware  commutations. 

■  generate  makefile  -  create  a  new  load  module  using  the  precedence 
information  in  makefile .  Hiis  tile  could  speedy  a  bmbliianie  as  the 
source  for  a  taiget  executable  module,  indicating  any  versions  ot 
source  files  within  the  build  1l1.it  .110  newer  than  the  target  must  he 
recompiled.  If  no  makefile  is  specified,  then  all  somce  language  Ides 
within  die  TCCS  directing  would  be  used  to  create  a  default 
executable  tile,  if  that  is  possible.  As  a  side  cited,  a  tep‘“  1  ol  which 
source  modules  wete  locompiled,  and  which  library  01  object 
modules  had  been  modified  since  last  generation,  is  produced. 

3  2  Implenieiuaiion  Details 

3.2.1  bile  Sir  lie"  lure  The  implementation  ot  3  CCS  depends  on  the  under  lyutf. 
operating  system  and  Us  file  struduie  II  the  file  system  allows  lor  creation  of  a 
subdirectory,  then  each  TCCS  database  would  be  in  its  own  subdirectory  If 
access  control  can  be  applied  at  die  dnectoty  level,  then  the  1 CC S  dnectory 
should  have  read  permission  granted  in  anyone  who  needs  access  to  the  data,  hui 
write  permission  denied  to  everyone.  I  des  wiihin  the  TCCS  dnectory  should  only 
be  modified  by  the  TCCS  functions  Some  systems  allow  this  by  giving  the 
TCCS  functions  special  privilege,  similar  u >  supeiucct  privilege  on  Unix  Oili  r 
systems  may  not  allow  this,  so  the  write  permission  would  have  to  be  placed  on 
the  individual  file* 

Since  the  TCCS  is  n>  vm  foi  storing  both  source  code  and  documentation,  the  tiles 
should  be  able  to  handle  all  ASCII  ciia.actets.  Although  11  is  intended  that  object 
modules  be  kept  outside  the  TCCS  diicvloty.  using  the  gcncrute  function  to 
remove  the  source  hom  the  directory  betoie  compilation,  there  should  still  be  a 
way  to  store  binary  data  This  would  allow  lot  documentation  that  includes  the 
output  of  graphic  systems,  such  ,ls  tiles  lor  a  laser  printer  or  output  from  a 
graphics  workstation  or  CAD  system  II  (he  tiling  system  den-s  not  have  a  feature 
that  handles  binary  daia  other  Ilian  objec  i  tiles,  the  UTS  should  include  tins 
functionality  Several  techniques  arc  available  for  this 

What  riles  aie  stoic-CI  in  the  3  CCS  dnectory  also  depends  on  what  the  operating 
system  allows  A  suggested  set  would  include  exactly  one  tile  lor  each  named 
element  Intui illation  on  how  the  sanous  generations  and  updates  nughr  Be 
handled  in  given  below.  I  ,ch  build, unK  would  be  stored  ,n  a  cepaiare  file  winch 
would  include  the  element  name  and  specific  mhuru.iimn  on  wlu.l,  generation  ot 
which  branch  is  to  be  included  in  that  build  3  Ins  would  be  c icuicd  h)  the  call  to 


build,  and  processed  by  generate.  Since  the  concept  of  a  build  is  new.  possible 
implementations  foi  the  build  deset iplor  ate  given  below.  Ii  the  operating  system 
directory  block  docs  not  contain  >ut I icicut  inhumation  about  files  to  maintain  the 
full  functionality  of  TCCS,  then  a  diieetoty  data  life  would  be  nmint  lined  within 
the  the  TCCS  diiceloiy.  Intel  mediate  hies  cieated  while  elements  ate  being 
processed  would  also  be  kept  within  the  T  CCS  dnectory,  and  deleted  alter  use. 
Journaling,  or  audit,  data  could  also  be  kept  in  a  tile.  To  minimise  ptoblems  due 
to  system  crashes,  whenevei  an  element  file  is  being  pioccssod  the  actual 
processing  should  be  done  to  a  tempoiat  y  copy  ot  the  file,  then  the  name  dunged 
at  completion  ol  pKxcssmg.  'I his  would  also  allow  any  function  to  be  abated 
bet  in  c  completion. 

3.2.2  1- lenient  l  ile  Contents  The  actual  contents  of  each  element  file  must  allow 
the  recreation  ot  all  versions  ol  an  clement,  including  earlier  ones.  It  the  system  is 
used  only  when  a  major,  and  approved,  change  need  be  recorded,  then  the 
inefficiency  that  results  from  tins  requirement  is  not  important  since  TCCS  would 
use  only  a  small  percentage  ot  total  development  icsoutccs.  The  element  lik 
requires  some  kind  ot  delimiting  character  to  diMerentiate  the  required  variable 
length  fields.  Using  a  single  mm-piniimg  character,  such  as  octal  001  (SOU),  at 
the  beginning  of  each  new  section  lather  than  dilfeient  cluuadeis  lor  each  section 
will  minimize  problems  caused  by  having  multiple  reserved  characters. 

A  munhci  of  fields  are  lequMrd.  The  original  text,  as  entered  by  enter,  should  be 
delimited.  A  field  containing  a  list  of  useis  who  arc  allowed  to  save  tins  tile 
should  be  included  unless  the  operating  system  access  control  is  sufficient  tor  this, 
for  each  call  to  save,  the  infoiination  rcqmicd  to  create  the  new  variation  from  a 
bas.  text  is  requued.  T  his  has  been  commonly  implemented  b\  speeitying  which 
fines  aie  to  he  deleted,  and  where  to  add  lines  that  have  been  added  i.e. 
instiuctums  tor  a  line  editor  to  change  the  base  text  to  the  e»n  rent  text.  It  the  way 
that  build  numbers  variations  makes  it  obvious  which  was  the  hast'  reel,  then  ic  is 
assumed  that  this  field  describes  changes  tv'  that  text.  11  it  is  not  Sv>  obvious  wh.it 
the  base  text  is.  which  might  occui  it  useis  aie  allowed  to  create  names  tor 
variations,  then  the  bunch  and  getiei.inon  that  this  new  generation  is  based  on 
should  be  named  When  the  edit  or  copy  function  i>  used,  each  delta  is  applied  in 
order  to  the  original  text  to  cieate  die  new  rext,  and  when  save  is  used  the  new  tile 
should  be  compared  to  die  base  text  and  a  new  delta  field  created.  A  checksum 
field  can  be  used  for  data  integuty. 

3-2.3  Hind  Spociticniicm  1  wo  methods  ot  spent)  mg  the  bind  ate  possible:  the  list 
method  and  the  dependency  method.  In  the  list  method,  a  list  of  all  documents 
related  to  a  particular  element  is  created  When  the  manager  invokes  the  link 
command  with  a  new  frinilname.  it  prompts  lor  the  contents  ol  the  bind.  It  the 
Inndname  already  exists,  it  prompts  toi  uddit.ous  An  appropriate  format  would 
be 

naniel  ::  name 2  ,  name  3 ,  n*m^4,  name 5 ; 
where  the  right  hand  side  lists  all  elements  that  might  have  to  be  changed  it  j 
change  is  made  m  the  element  on  the  left  hand  side 

In  the  dependency  method,  a  notation  snnil.u  to  that  of  the  makefile  syntax  o  used 
to  show  that  j  change  in  an  element  may  be  propagated  Unlike  a  makefile. 
however,  such  propagation  mas  oveur  m  both  directions  I  or  nouiion.il  puqvwes, 
define  up  to  be  low  aids  the  ux»i  Sy  wem  AVi juiremerix  N/vi  iju  -Hum.  and  down 
toward  cixle,  then  sideways  can  be  omsideied  an  clement  at  the  same  level  <>n 
another  branch  of  the  tree  Consider  tlu.  example  ot  a  change  \n  the  algorithm 
described  or  listed  m  a  lop  1  c\el  S«>ftw are  design  dovument  A  change  in  it 
would  pi  op  agate  up  *o  the  Software  Requirements  IkKument.  ami  down  the  tree 
to  (tic  code  diKument  However,  a  k lunge  m  the  test  Civic  would  only  propagate 
sideways  to  the  test  dot.  u  me  mat  ion.  and  a  change  m  the  test  dtvumcntaiion  v.ould 
propagJte  sideways  to  the  tesi  kodc.  and  aho  up  to  the  software  test  plan.  An 
appropriate  fin  mat  tor  the  dependent)  in  a  bind  would  be 
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n an\e  1  <  -  >n air\a2 


I  ‘K«re  I  -  Sample  Document  Dependency  Graph 


naniel-  >naxnei 
name  1  <- name  4 

wlun’  each  actual  inict -element  dependency  requites  only  one  enhy.  In  the  fits*, 
example  eu'iy ,  a  change  in  either  element  may  Kquuo  a  change  in  the  othci;  in  the 
second  eniiy  a  change  in  tunnel  may  iequiie  a  change  in  element  name2  hut  not 
the  level v;;  the  ihiiU  entiy  shows  iii.il  oidei  can  he  levelled  by  using  a  ditfeicnt 
symbol.  See  tiguie  1  lor  the  paitial  giapli  ot  a  simple piojeet  involving  (TO  ).l . 
Table  i  shows  both  the  list  metluKl  and  dependency  metluHi  cut  lies  m  a  !>md 
deseiiption  tot  CPC1  1.1. 

Thcicaltci,  whenevet  an  clement  of  the  bind  is  modified,  all  i cl  * led  elements  aic 
mail  ed  win  the  MR  number  and  any  invivat ion  of  that  element  will  result  in  a 
message  that  MR  nutnbet  has  not  been  incoi  pouted  into  the  element  yet.  II  an 
clement  is  a  member  ot  multiple  hinds,  the  person  modifying  the  element  is 
Queued  to  sec  which  ones  aic  appiopuaie  to  activate.  Por  example,  if  the  MR  that 
led  to  a  C'CR  approved  change  is  known  to  .ilfect  only  the  subsystem  ot  which  the 
element  is  a  part,  and  a  hind  has  been  defined  toi  that  subsystem,  then  lhat  bind 
and  not  the  total  system  bind  can  he  named. 

•1,  Lise  ot  Automated  Tools  in  the  Soltyvatc  1  ievelopment  Cycle 

DOp -ST \)  2  lb?  *  desciibes  a  staiulaul  icfeience  sottwaic  development  cycle 
winch  a  sottwaic  developer  should  strive  to  emulate.  This  ptocess  can  be  assisted 
by  the  use  ot  a  tool  which  implements  the  tunctions  of  the  canonical  TCCS 
dcscnbcd  above.  1  lie  following  sections  descube  how  such  a  tool  would  be  used 
during  sottwaic  development  ot  a  scenic  computet  updating  system.  I\k  ument 
names  in  italics  ate  thvunicnts  specified  in  the  standaid,  and  described  in  related 
Ifua  Item  Desciipiious.  lt.udw.uc  documentation  and  ao>  diawing.s  gcociatcJ  by 
CAP  equipment  could  also  he  included  in  the  confirmation  accounting,  hut  tor 
reasons  ot  brevity,  and  ba  ause  the  example  DOP-S 1  D-2lh7  is  a  sol  (ware 
standard,  their  use  is  not  described  here. 

4.1  Recpinements  Development  Phase 

Hie  system  piOjcct  manager  initially  sets  up  accounts  toi  each  programmer  or 
analy  st  involved  ut  the  piojeet,  and  each  piogiammer  or  airdyst  is  given  access  to 
a  dll  a  toiy  ol  text  tiles,  an  editot  and  word  processor 'lonnailcr.  Shanng  ot  woik 
among  le.im  members  \!huiK1  be  easy  to  accomplish.  During  requirements 
development,  each  team  member  vstites  s|K\  itn  sci  lions  o!  the  requirements 
dvvumont.  tollo-vmg  the  format  shown  in  the  Sturuiarth  ami  l’r,u  olun^  Manual 
If  >Uili  a  m.imi.iJ  d»K.*s  not  alicady  c\is|.  a  diaft  version  of  it  should  be  written  by  a 
small  con m m tee  ol  experienced  team  members  It  it  addresses  only  code  and  not 
the  format  v>r  other  divunients.  then  the  team  leadci  should  develop  a  toi  mat 
consistent  with  the  way  the  conligiiiution  ,k counting.  tool  will  sioie  ilic eventual 
texi  tiles  1  lie  am t  l'r,n  t'Jur<-\  Manual  is  Mie  only  divuriicnt  dial  need 

not  be  entered  into  the  K  C  S  database,  although  having  an  online  copy,  complete 
with  blank  torm.it  examples,  is  doiijhlc 

I  ot  It.'  and  A 1  systems,  the  formal  w\unty  jvluy  nuxicl  a:iJ  the  consistency 
ptixif  .ue  among  the  le-milemcnts  document  generated  at  this  phase  I!  an 
CMsoiig  in. Kiel  is  being  used,  then  ibis  v  an  >  e  replaced  h>  a  icteieiuc  i.»ihc 
existing  dese  i  iplioii 

Once  the  project  manager  sees  th.u  e.i.  b  m.  diori  ot  the.  J.Kumen*  has  beti* 
completed  by  the  assigned  analyst,  although  stiil  subjevt  to  change  by  the  m.magei 
or  as  the  result  ol  mier.klion  with  other  team  memU'  s.  the  manager  um.»  the 
setup  I u ik t ion  to  i.  icate  a  database  1  a.  h  elcmciu  ot  the  lequiremeniv 
diKU mentation  is  placed  m  the  daijba.se  using  the  enter  lu?ki*on  IXkumeiiLs  that 
dep«.  nd  on  one  another  should  be  represented  as  a  /»;'i.i  suing  ‘lie  fink  function 
Once  this  database  has  been  created,  the  manager  and  team  revise  the  d.vuments. 


l  iible  1  •  Iqui'.iUnt  1  CCS,  CMS.  and  SCCS  functions 


TCCS 

CMS 

setup 

Ckl.ATt  I.IMRARY 

mkdir 

enter 

CKl  ATI.  Mi  N11.NT 

admin  -n 

edit 

Kl.SI  KV1. 

gtt  e 

save 

RliPl  ACi: 

delta 

copy 

M  l  CM 

get 

audit 

CMS  SI  l()\\ 

yis 

build 

CR!  All  Cl  ASS 

delta  tM.i 

genet  ate 

MMS 

nuke 

link 

N  A 

rra 

Table  2  -  Itind  Spi-v ific-tiun  for  ( T(  I  1.1  in  a  Simple  System 
List  Method 

CPCI  13::  CPCI  1.2.  Unit  1  1 

C^Cl  1.2  ::  CPCI  1.1,  Unit  1  2 

Unit  Teat  11  Teat  Deac*ipt ion  1 
Unit  Tsat  12  ::  Test  Description  1 
Detailed  Design  1  . :  CPCI  1  1,  CPCI  1  2 

Dependency  MvthoJ 

CPCI  1  1  <->  CPCI  1  2 

CPCI  1  l  <-  Detailed  Design  1 

CPCI  1.1  ->  unit  Test  1  1 


possibly  by  luting  other  team  members  revise  portions  of  each  document.  1  lie 
process  involved  in  doing  tins  is  straighifm  ward.  The  munagci  allows  all  team 
members  who  will  revise  a  section  to  have  read  access  to  the  appropriate 
elements.  Then  the  team  member  uses  copy  to  get  a  copy  of  die  clement,  an 
editor  to  do  die  rewrite,  and  gets  approval  ol  the  manager  to  reinsert  the 
document.  The  project  manager  uses  edit  to  retrieve  the  document,  uses  die  editor 
to  replace  the  changed  sections  with  the  approved  files  from  his  directory,  then 
saves  the  modified  document.  During  the  rditVsave  operation  the  database  is 
locked  so  that  no  one  else  can  execute  an  edit  function  on  that  clement.  It  every 
team  member  were  allowed  to  use  edit  then  each  document  would  have  to  be 
broken  into  many  smaller  documents  so  that  sevctal  team  members  could  each 
work  on  one  section  at  a  time.  This  is  feasible  lor  source  code,  but  not  desirable 
for  documentation.  When  the  new  section  is  saved,  die  automated  tool 
automatical .y  notes  what  changes  were  made  and  who  made  the  changes. 

Ones  the  documents  are  ready,  the  Configuration  Control  Board  (CCB)  reviews 
the  requirements  documents.  Any  changes  they  require  can  be  entered  by  the 
team  manager  by  using  edit  and  save,  giving  the  minutes  of  the  CCB  meeting  as 
the  reason  for  the  change. 

4.2  Functional  .Specification 

At  the  next  phase  of  development,  several  documents  are  created.  In  each  case, 
the  same  procedure  may  be  used  for  text  documents  as  was  used  for  the 
requirements  document.  Thus,  new  database  elements  are  placed  in  the  system  for 
the  Software  Requirements  Specification,  the  Interface  Requirements 
Specification ,  the  Software  Configuration  Management  Plan,  and  the  Software 
Quality  Evaluation  Plan.  At  the  A1  level,  the  Vcrif nation  Plan  is  included.  Bach 
element  should  be  linked  to  its  appropriate  hinds  by  the  project  manager.  In  each 
case,  enter,  ropy,  edit,  and  .save  are  used  as  above.  I*  very  use  of  save  prompts 
for  a  MR  number  it  the  document  has  previously  been  approved  by  the  CC  B. 

4.3  Developmental  Phase 

During  the  developmental  phase,  the  modules  identified  during  the  functional 
specification  phase  arc  filled  out.  first  with  cither  graphical  representations  of  the 
algorithms  to  be  used  eg.  flow  chares,  or  textual  representations  such  as 
Programming  Design  Language  (PDL.r.  In  the  case  of  textual  representations,  the 
same  techniques  niay  be  used  as  for  other  documents.  For  graphical 
representations,  especially  those  produced  on  a  separate  device  such  as  a  CAD 
workstation,  the  copy.  edit,  and  save  functions  can  be  used  over  a 
communications  line  connecting  the  workstation  with  the  main  computer,  it  such 
a  communications  line  is  not  tea'  Me.  then  some  kind  of  common  medium  such  as 
a  floppy  disk  or  tape  will  be  use,..  In  either  case,  the  graphical  representations 
may  still  be  kept  under  configuration  control  by  the  automated  tool. 

When  coding  starts.  Configuration  Identification  conics  into  play  with  the  naming 
and  numbering  of  modules .  rI  lus  can  easily  be  enforced  by  the  project  manager 
using  the  enter  function.  Lach  new  element  should  also  be  linked  into  its 
appropriate  binds.  T  est  modules  sic  also  generated  for  the  simple  tests  used  by 
the  programmers  to  unit  test  these  modules.  A  typical  sequence  of  interactions 
with  theTCCS  database  woul  proceed  as  follows.  The  manager  enters  a  code 
segment,  giving  the  lust  line  ol  the  module  including  the  module  name  and  calling 
sequence  as  described  in  the  interface  document.  'I  ho  manager  also  enters  a  bl  ink 
unit  test  module.  He  links  them  together,  and  links  the  code  module  to  iis 
description.  The  programmer  creates  a  copy  *  t  the  document,  tills  out  the  code 
with  reference  to  a  copy  of  the  Bow  chart  or  PDL  representation  of  ihc  module. 

He  writes  .t  unit  lest  procedure  that  calls  the  module.  He  compiles  both  pieces  of 
code,  executes  the  simple  test,  and  continues  the  lamiliar  debugging  cycle.  Once 
the  code  passes  the  programmer's  unit  tests,  the  project  manager  calls  edit  to 
place  the  initial  version  of  the  module  and  unit  lest  code  mu*  the  database,  or  else 
gives  the  programmer  temporary  permission  to  per  form  the  .same  operation. 

Once  sulficicnl  code  has  been  generated,  the  test  plan  included  in  the  Software 


Quality  Evaluation  Plan  will  include  some  inter  me  Jiaic  testable  builds.  The 
Quality  Assurance  team  niembeis  create  matejiles  that  describe  these  builds,  and 
write  die  required  tests  using  a  procedure  similar  to  that  described  above.  The 
generate  function  is  used  to  create  these  intermediate  Inn  Ids.  The  build  function 
can  be  used  to  simplify  the  makefiles  by  creating  bmldnaines  for  the  test  builds. 
Once  the  whole  build  compiles  and  loads,  the  tests  are  run  and  any  errors  oi 
inconsistencies  me  noted. 

Erroneous  test  results  require  debugging  and  modification.  Since  all  the  modules 
arc  under  configuration  control,  debugging  is  riot  as  simple  at  this  stage  as  at 
earlier  stages.  Lach  programmer  must  make  sure  that  any  changes  made  do  not 
affect  other  modules.  Again,  copy,  edit  and  save  are  used  to  reprogram,  unit  u-st. 
and  replace  modules.  Once  a  build  has  successfully  met  its  te*sts,  the  CCB  meets 
and  approves  all  modules  involved.  Any  further  changes  to  a  module  requires 
CCB  approval  and  a  MR  number  as  justification. 

4.4  System  lntcg-.qion  arid  resting 

Once  all  intermediate  builds  arc  finished,  the  cntuc  system  may  be  tested.  If  the 
system  is  to  run  on  the  development  system,  this  is  fairly  easy.  It  is  slightly  more 
difficult  it  the  system  *s  being  cross  compiled  to  another  computer.  The  Quality 
Assurance  team  uses  build  or  generate  to  create  a  test  system,  including 
compiling  the  lest  routines.  The  tests  are  run.  any  anomalies  are  noted,  and  the 
reports  are  sent  back  to  the  manager  for  disposition.  This  should  be  the  first  nine 
that  requirements  and  functional  specifications  are  considered  for  modification. 
Some  major  requirement,  such  as  timing  or  capacity,  may  not  be  met  by  the 
system.  In  such  a  case,  either  the  requirement  must  be  loosened,  i r  a  major 
redesign  may  be  required  tor  ihc  system.  Any  change  to  requirements,  design  or 
code  must  be  approved  by  the  CCB.  Any  change  to  requirements  or  specification 
must  be  propagated  through  the  design  and  code;  any  c  hange  to  the  specification 
or  design  must  be  propagated  through  the  code.  I  he  i  C  VS  makes  tins  pr<  paganon 
easy  since  requirements  can  he  traced  up  and  down  the  chain  of  documentation  by 
cross  references  to  other  documents  and  code  segments  within  each  database 
element. 

4.5  Production  Phase 

Once  the  final  build  passes  all  tests,  and  after  the  NCSC  team  completes  testing 
and  approves  the  design  and  implementation  the  configuration  accounting 
database  is  archived  tor  reference  purposes.  A  clean  copy,  without  any  historical 
data,  is  made  of  all  relevant  documents.  All  design  documents,  such  as  flowcharts 
and  PDI .  descriptions,  and  all  source  code  modules  are  also  copied  in  a  form 
stripped  of  all  historical  data,  (»em*nite  is  used  to  produce  production  copies  of 
the  system  trorn  this.  However,  Configuration  Control  does  not  end  here;  it 
continues  from  tins  checkpoint  1  he  clean  copies  of  all  code  and  documentation 
«uc  stored  in  a  new  database  kept  by  the  configuration  accounting  tool,  and  dm  ing 
the  maintenance  phase  any  changes  to  code,  spec  i  lu.  at  ions,  design,  or  possibly 
even  requirements,  it  approved  by  the  CCB,  ate  entered  into  the  database  using 
edit,  l  he  link  function  is  used  to  describe  the  relationships,  between  the  user 
manuals  and  maintenance  manuals,  the  operational  test  suite,  and  the  code  source. 

The  functions  audit  end  generate  can  he  used  to  piovide  the  facility  to  ascertain 
that  only  intended  changes  were  made  to  the  system  ver  sion  being  produced.  I  he 
audit  function  can  be  invoked  to  list  all  elements  ihat  have  been  added  to  the  code 
since  the  last  version.  All  of  these  changes  must  have  been  controlled  by  the  CCB 
and  only  entered  by  appiopnate  personnel.  Then  when  generate  is  used  to  creme 
an  object  tape  of  the  system,  ii  wdl  create  a  report  of  winch  source  modules  had  to 
be  recompiled  due  to  changes  since  the  last  veision.  A  comparison  ot  these 
reports  would  show  any  discrepancies  if  cither  the  makefile  had  been  tampered 
with,  or  an  unauthorized  change  had  been  made  to  a  source  file  after 
circumventing  the  TC’CS  system. 
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caudit  invocation:* 


audit  <element  lisl> 


■^build  invocation* 


build  <buildname> 


cbuildnaine 


<generatc  invocation > 

<makefilc> 


generate  <makefile> 


::  <fllenamc> 


clink  invocation* 


link  <bmdnume> 


<bindnamc> 


<namc> 


Implementation  Dependent  Identifiers 

<directory  name-*  is  a  single  identifier  dial  satisfies  the  local  operating  system 
syntax  for  naming  a  common  group  of  files.  In  a  tice  style  directory  filing  system, 
this  would  be  the  name  of  a  subdirectory.  In  a  flat  file  system,  this  would  be  the 
common  prefix  that  all  flies  in  the  group  use. 


APPENDIX  -  Backnv-Naur Syntax  c.fTCCS 
Implementation  Independent  Definitions 
<session>  < session  body>  end 

<scssion  body>  <enipty> 

|  <session  body*  < function  invocation: 

<f unction  invocation >  ::=  csetup  invocation* 

|<enter  invocation> 

|<cdit  invocation> 

|<save  invocation > 

|<copy  invocation* 

|<audit  invocation* 

|<build  invocation* 

Dgeneraie  invocation> 

|<link  invocations 


<sciup  invocation > 

setup  <dircctoiy  name> 

<cntcr  invocation* 

::=  enter  <clerncnt*  |  filename >) 

cedit  invocation* 

edit  <elemcnt  specifier >  |<tilenamc>' 

<save  invocation  > 

save  <list  of  elements:* 

^element:* 

<namc* 

<c lenient  li.st> 

<h.st  of  elements* 

I  chuildnaiue^ 

{  <l)iiidnanic> 

<list  of  elements* 

^element  specifier* 

Hist  of  elements >  < element  specifier- 

<filenan.e>  is  a  single  identifier  capable  of  specifying  a  contiguous  text  or  binaiy 
file.  In  a  tree  structuied  airectory  tiling  system,  this  would  be  a  (possibly 
aohreviated)  pathname.  In  a  flat  filing  system,  it  would  be  the  full  name  of  the  file 
unless  the  operating  system  allowed  part  of  the  prefix  to  be  assumed. 


<name*  is  a  default  text  string  that  the  opeiating  system  command  processor 
would  recognize  as  a  valia  argument  to  a  function  call.  The  name  should  be 
passed  mtau  as  a  text  stung  idcntilying  the  TCCS  element  or  buildname  to  be 
processed. 

<clemcnt  specificr>  is  a  valid  name,  as  above,  plus  whatever  additional  text  is 
required  to  specify  a  partk  alar  release  or  level  of  a  main  or  side  branch  of  an 
element. 
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Abstract 

This  document  i/esrrihes  the  approach 
taken  at  Puget  Sound  Power  and  Light 
Company  to  implement  IBM's  Resource 
Access  Control  Facility. 

Introduction 

During  the  past  ten  years,  a  very  signif¬ 
icant  shift  of  focus  has  occurred  in  the 
information  processing  industry.  This 
shift  of  focus  has  emphasized  not  only 
output  and  information  deliverables,  but 
internal  controls  as  well.  Several  forces 
have  Conti ihuico  to  this  shift  of  focus 
including  federal  statutory  requirements, 
state  and  local  government  regulations, 
accounting  ;tml  audit  firms  interpreta¬ 
tions  of  data  seem  iiybiuei  nai  connoi 
regulations  and  the  micro-computer  inv¬ 
olution  which  has  brought  tremendous 
computer  power  at  a  relatively  low  cost 
--  power  which  can  be  used  for  legiti¬ 
mate  and  illegitimate  purposes. 

To  illustrate  this  shift  of  focus,  the  im¬ 
pact  of  the  foreign  Corrupt  Practices 
Act  (or  I  CPA)  should  be  highlighted. 
This  important  federal  legislation  en¬ 
acted  m  the  late  1970  s  attempted  to 
bring  accountability  for  un-cthical  busi¬ 
ness  practices  to  corporate  directors  and 
offieeis.  Ilowevei,  amendments  to  this 
act  and  interpretations  by  legal  and  au¬ 
diting  national  firm  .  extended  this  act  to 
cover  not  only  un-cthical  business  pi.-ie- 
tices  but  crimes  involving  computer  re- 
souices  when  these  lesouices  a>e  not 
pioperly  protected.  I  bus,  the  impor¬ 
tance  of  internal  computer  controls  was 
brought  out  of  the  technical  i calms  and 
into  the  boaiilronm  wlieie  n  became  a 
legitimate  business  concern  —  the  proper 
place  for  this  issue. 

Data  security  and  internal  controls  have 
become  corporate  business  pioblems  ami 
not  technical  problems.  Thus,  oui  im¬ 


plementation  of  information  icsourccs 
controls  had  to  be  addressed  first  at  a 
corporate  level  and  secondarily  at  a 
technical  level. 

In  our  company,  the  need  for  a  security 
package  was  highlighted  by  our  external 
and  internal  auditors  who  commented 
on  the  need  to  install  seemity  packages 
and  improve  controls.  Ibis  need  was 
further  highlighted  by  federal  and  state 
legislation  such  as  the  Privacy  Act  and 
the  Washington  Computer  Trasspass 
laws  (RCW  9A.52.!  10)  which  further 
define  Coiporate  responsibility  and 
computer  crimes. 

T  hese  combined  factors  and  cost,. benefit 
opportunities  prompted  management  to 
authoii/e  the  purchase  of  a  data  sccuiity 
package  and  the  cteation  of  an  Infor¬ 
mation  Systems  Access  Adniitiistiation 
gioup  to  manage  the  implementation  of 
the  package  and  the  daily  management 
of  access  requests  and  ptofilcs. 

This  document  tlesetil.es  the  appioaeh 
taken  at  Puget  in  installing  out  tlntu  se¬ 
curity  package  and  the 
problems  solutioiis  associated  with  such 
tin  implementation.  A  special  note  of 
appicciation  is  extended  to  out  Manager 
of  Infoi  ination  Systems  Quality  Assur¬ 
ance,  Jim  Hall,  for  his  support  dining 
the  early  stages  of  Tiis  project.  In  addi¬ 
tion.  Rogoi  Doit/  of  i  ct  'iiiical  Suppoit 
significantly  and  enthusiastically  con¬ 
tributed  to  th"  success  of  this  project  by 
developing  installing  systems  interfaces 
and  piovidmg  valuable  input  vvhcie 
philosophical  decisions  were  requited. 

Defining  Corporate  Policy  and 
Procedures 

Sim  neiiial  emit  mis  and  data  seeutiiy 
issi  ate  management  issues,  it  was 
impeiative  that  out  amputate  manage¬ 
ment  cleaily  stated  official  corporate 
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policy  i',i  these  issues  Our  corporate* 
police  on  llic’sC  KsUi  S  is  stated  111  till:' 
(orponitc  Policy  Guide  Section  id 
"intomiiitioc]  Data  Seenriiy"  winch 
stales: 

"Ad  employ  ,‘<s  arc  responsible  lor 
prelecting,  iiiili/irtK,  ond  releasing 
inloi  niation  icsoiirccs  of  the  Com¬ 
pany  in  a  mamict  consistent  will;  the 
direction  uni!  standards  set  by  the 
l.itoiual  <’ontro'  Review  commit¬ 
tee". 

In  ;ulvl  it  it  >n .  C  I’C  i-3!  I'uitluT  d.niiies  the 
inieiu  dI  this  policy  In  staling  that: 


"Inloi  inndon  Resources  within  a:iy 
company  organization  are  property 
of  the  company  The  Company, 
through  it:;  employees,  lias  a  respon¬ 
sibility  to  balance  the  requirements 
for  iiifonnai ion  with  the  need  >o  se¬ 
cure  its  information  resources  ftoin 
the  threat  of  willful  or  accidental 
<ti  struct  ion,  modification  and  iinati 
liioh/ed  disclosure.  Responsibility 
to;  the  seem  it y  of  iulonin.tioii  rests 
wiih  t!ie  individuals  having  pos¬ 
session  or  knowledge  of  the  infor¬ 
mation". 

A  itiajoi  key  concept  in  this  policy  sec- 
tt  in  is  (lie  definition  ol  information  Re¬ 
source  Administrators  (IRAs)  who  me 
tin  s'tin s  ,nUi  manage, s  who  I  a \ e  au 
Ihn.'ed  the  ciealiott  and  i.tainlcitttncc 
of  corporate  data.  I  hese  iRAs  deloi- 
ntine  who  can  and  can  no:  access  then 
-l.iln.  |  hot  lToic,  Cot  poi  ..Me  iiiloiinatloit 
S\ stents  heeame  a  custodian  (and  not 
iiiiiiii  a  <  I  lit  t  it  e.l  i  .a  loi  I  j-i  the  d.il.i.  II  a 
toi  pm  ate  e:::p|.i\ce  needs  .access  to  a 
specific  lesotiiic.  Access  Vlntiitisti.ulion 
umidiiiatcs  tiic  sijm.iluic  anpiocal  pioc- 
css  and  loi  waids  these  'isjiies;s  to  the 
piopci  I  HAs  w  :w>  ,.tlh.ei|tic;,tl\  approve 
and  o;  dens  thc'C  ii'quests.  Thus,  (  ot- 
pui.iir  |  aloi  ntatio't  Systems  became  a 
root ilou itoi  nj  i/cccsv  and  not  a  decision 
makci . 


It  should  he  note,/  that  impioper  I'oml/ioy 
mol  i -i  disclosure  nj  infortunium  is  sub¬ 
ject  to  illsciph'iorv  lift  ion  os  oh '/,  'ICii  m 
am  Corporate  Policy  < iuide  ssetion  It 
lit  hies. 


Access  Request  I  t  (icedtircs 

I’loeedines  delineating  steps  tYi;i'..'vd  to 
tetpicsi  giant  access  are  desciibod  in  otir 
Stamiaids  and  I’toccdiiics  I'taiin.ii.  In- 
formation  Systems  Guide  section  I  III. 

was  ereatctl  in  oulci  to  dncti- 
inent  [uoeetluies  to  be  followed  vhen 
tctinesiiitj:  access  to  or. hits  systems  --  t.e. 
ISO.  KOSl ’Oh,  OK'S.  VM  ('MS. 
Model  20  ),  etc.  -•  oi  othei  Inloi  ni-ttion 
Svsu  ms  icsourccs  uttder  the 
i.'t.stiulitinsllip  of  the  Cut nitrate*  Inlot- 
niation  Systems  department. 

As  discussed  m  ('!’(.•?•}.  the  Comp  toy. 
i h i* until  its  employees,  has  a  tespoiisi- 
hilily  to  balance  the  letpiitemenl .  'ot 
inioi m.'tioit  will;  the  iieci'  to  secure  its 
iofoimatioit  resoi.'ices  lion*  the  ducat  of 
v  iillul  ot  ttccidenlal  destruction.  inodtli- 
cation  aitit  nnaollioi  i/cd  divlir.tncs. 
Central  access  com  nils  .ate  thcicfoie  re¬ 
el  mi  etl  to  secure  tin  sc  in  lot  mat  ion  re- 
somee  and  protect  them. 

It  should  he  noted  that  uwponsibtlily  lot 
the  senility  of  mloi  m.tiion  tests  with  the 
individuals  having  possession  ot  know¬ 
ledge*  ol  the  inloi  niation.  1  hen.Tore,  ac¬ 
cess  control  services  ate  piovidcd  in 

oidci  .o  minimize  itnpiopct  handling  ot 
elisrlosme  of  ,nfo:  niation. 


Selection  ol  ::  Package 

A  leehtii' ml  task  force  was  loinied  in  the 
Si'niine:  ol  mss  to  evaluate  .tecess  con¬ 
trol  sol:  a  an- systems  genet  ally  available 
in  the  iii.aiket.  litis  task  luice  was 
composed  ol  Ouahty  Assuiancc,  Data 
Aeiininistiation,  Computet  Opetanons. 
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I' inn ni'i ;i 1  Systems.  Applications  l)c\cl- 

opment.  Cu-.uiiiiei  Nci  Civcs,  Chen  Ser- 
xiees,  liik'rn.'l  AikIiI  :nui  li'climcal 
Smin’s.  I  iu'  mission  ol  llus  lask  loice 
was  to  ik'U'Inp  a  criteria  winch  would 
!>C  used  lo  I'salaaH'  access  contiol  solt- 
wan-  packages  lli.il  aic  cuiiendy  i.  ‘li¬ 
able  ili.it  won!  d  mil  in  i In'  VM 
i'll  \  i  i  mi  men  t  ami  t  lie  MVS  XA  cn'.iinn- 
llH'lll. 

llio  nNiiall  strategy  called  I'm  each  ic- 
miuicc  ill  a  1 1  auc  i  technical  task  I'm  a’ 
in  I'm  lii'  i  in  pi  ox  ide  a  si' i  nf  iss  ui's  anil 
ii'ijiiii iiili’iils  ini  t hei i  specific  aica  ul 

ii-sp  iiisihiim, .  I  hi'^i’  K’i|iiiiciin'nis 

would  du'ii  ha  used  in  tmli'i  in  c'aluale 
access  contiol  packages  and  make  a  ic- 
uininii'iidatiiiii  in  managemcni. 

1  liu  task  loice  ili'l uii'il  ilio  mijiinal  ci  itc- 
i  a  for  soli'i'i ion  ’oasi’d  on  ii'i|iiiii'illi'iils 
dial  dm  selected  '•.I'lwaio  package  iniisl 
h  oi'  sufficient  maiki'i  sliaif  m  oidi'i  in 
ensure  dial  dm’  xcmloi  selected  would 

i'i'  ;»»m0  ii«  <i  i(iUlil|'iiO  ^v’iKJui 

snliwaii'  i'll  \  i  i  on  moil ' .  Ii.  addtl  inn,  dm 
solick'il  stiliivau’  package  niusi  inn  in 
liu-  MVSX.v  i'ii \ n on iiii'ii I  and  m  t In' 
VM  SI’  s'n\ iinn mein  in  older  in  I'lisurc' 
pinii'i'lion  for  mu  mi'iall  I'niiiniinu'iil, 
ii'siiici  aiTcss  in  systems  in l i'i  fai  l’s  and 
I'nsiiii'  dial  physical  inodiiicalloiis  In 
sllait’d  li’sniiH'i's  Wniild  hi'  recoitni/ed 
amiss  opi'iadiip,  enx  imiiments. 

Hasi'ii  nil  dii'si'  in il i.il  ii'i|iiiu'iiii'ills.  the 
lask  foice  ii'diu'i'd  ihi’  numbi'i  nf  pack 
ages  in  thti'e.  1  Ih'\  wi’ic  At' I  s’ ,  RACI 
and  iOl’SI.CKI.L 

DuiiP)',  t.'ii:  lask  foice  I'lahialinll  ses¬ 
sions.  il  uas  iinlcd  dial  at  I  In’  lime 
!OPS!.CRi.|  was  tunning  in  the  VM 
cm  i;  oiniK’iit  only  in  sc  lee  ted  hei.i  sues 
eii', iruninenis  and  dial  die  VM  compo¬ 
nent  was  mn  scheduled  I’m  geneial  ie- 
li’.'se  availability  mu i I  kale  1'tSs  eatly 
l‘»Xf».  In  adihl inn ,  nin  external  audilnis 
suggested  dud  mn  cnxirnnmcut  shoulil 
Ian  consider  access  eon  I  ml  soliwaie 
packages  that  an'  i  mining  in  pioducdon 
environments  I'm  less  dial  one  yeai. 


Hasi'd  on  this  ciilcii.i.  the  packages  i.n- 
ilei  considi'i ai inn  wi'ie  leiluced  in  mo: 
ACI  2  and  RACI  . 

1  hi'  disk  foiiY  ili'l I'lnpeil  a  set  nl  ic- 
ipiiieiuenis  which  wen  used  in  eianiau 
bulk  packages.  Il  was  fninul  dial  holli 
ACI  2  ami  R  \(  l:  met  all  die  inhniial 
and  ciiil  nsi'i  lt'ijuiii'menls  fmuinlaied 
by  die  disk  foiee.  Si'ieial  changes  had 
oceiiied  in  die  Iasi  IS  iiinnihs 
(t'JSI  l‘>S5)  which  made  KACI  and 
ACI  2  ii'iy  siniil.ii  in  ease-nl-iise  eiiai- 
aetei isiies  and  flexibihti. 

In  addiiion.  IBM  had  changed  the 
soilin'  code  ilisii  1 1> u i in n  policy  Ini  cci  - 
lain  pindllels  uildci  MVS  XA  when'  die 
sou  ice  Ini  opcinliug  systems  modules 
and  m hei  selected  piudiii'ts  is  nut  ic- 
leased.  Sinee  ACI-2  iclies  on  non- 
siandaid  ii. lei  faces  and  finnl-eiid 
modules,  sei eial  ACI  2  useis  speculated 
dial  lliis  change  in  HIM  policy  had 
caused  a  pinhlem  I'm  eiineni  and  up- 

luil.lii:?  n.  ii  in  .iiiiiihuii.  mmiic 

ACI  2  customers  and  mhe:  indiistiy 
specialists  impiied  dial  pioiluets  such  as 
ACh.2  .lie  in  a  pencil  nf  li.msjdmt  suin' 
most  nl'  ilieii  iiiiedaei's  in  die  updating 
system  would  liaie  in  be  icwiitteii 
and  m  modified  in  oulei  in  aeeoniodate 
changes  ia  MVS  XA. 

VVith  Release  1.7  nl  RACb,  die  1 1 1 M e r - 
cnees  in  pi  ml  tu  t  philosophy  and  capa¬ 
bilities  ate  almost  non-existent.  I  Ins 
was  not  the  ease  in  pieximts  icleascs. 
I  lie  net  effi'i-t  is  dial  today,  theie  is  xety 
hide  dilfeienee  I -it  ween  the  piniluets. 
In  aililiiinn,  IBM  ileelaieil  RACI  as  a 
Miatcgic  pindiiel  and  as  such,  an  iille- 
gialion  nl' die  data  manngnii'iU,  opcint- 
ing  system  capabilities  and  iiu'ess 
contiol  facilities,  We  felt,  is  inevitable. 

I  lieielme.  the  technical  task  foice 
iinaniitiously  leemn mended  dial  RACI 
shmilil  be  select eil  as  mu  access  coudol 
.software  package.  A  siimm.oi  nl  ic- 
i| ii i i I'ineii is  di'n'lnpnl  by  the  task  Imee 
aie  meluiled  in  the  document  entitled 
“.Icee.i-i  l  'cnt-ol  Saji  ware  Technical 
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J:  hi. 'i/a  tioii"  {  UijiuM  22,  J'/S.-i)  available 

upon  icq.iesl. 


SMSM.MS  f  AI  IO.N' 

SYSTEMS  sot  I  WAKi: 

INSI  AS  I.ATION 

I  list  alb' t  ton  of  the  O pi  rating  Systems 
components  t'.»i  Ihh!,  environments 
(\'M  SI1  nun  ...VN.XA)  is,  in  pmeiai 
Villi-,  ;i  by  tiii'-hook  pM-cess.  b.ssi'll- 
ti.illv.  IBM's  SMI’  pioieilm ex  .uid  VM 
install.!! inn  pioccdtucs  ;iu'  followed  and 
ilk'  components  me  puiporlv  tushd'cil. 

Ii  '•hotihi  he  noted  1 1 1 :i t  we  we  eleeiei1 
in. l  in  implement  .:  slutted  ilnt.ih  ise  en- 
'  iii'iimcnt,  since  il'e  \  MSI*  and 
MVS  XA  enviii'iimei's  .ire  me  nut 
total!"  integrated.  In  !*! it ioii.  we  !e!t 
lh.it  i he  li'.ks  assueiak'd  with  utstauii.g 
n  s!iaie<l  eiiviiuiiiiieiii  oiii'vcif.h:eil  Bt 
possible  benefits  assueiateil  with  such  aii 
implementation. 


usi;k  h)i:ntii  icatson 

One  -  the  operating  system  eumpoiients 
aie  insi, nlli'il,  the  next  logical  sup  is  to 
identify  al1  system  users.  I  Ii  is  pi  need  it  re 
necessitates  i  rt.ninion  melhml  of  klen- 
tifieation.  Wi  eleeteil  to  use  a  Zxxxxx 
stmiilanl  vltere  xxxxx  employee  num¬ 
ber.  By  using  the  employee  nutnbei, 
RACT  identification  wuuhl  remain  con- 
stant  even  if  the  employee  clumped 
names,  wot  king  locations  ot  job  titles, 
by  being  unique,  the  employee  nunibei 
also  pioviilcil  an  excellent  iilentiliei  that 
con lil  be  used  in  tandem  with  'Inman 
Resources  sunportinp.  systei'is. 

Once  this  stamlard  was  aiiopted,  non¬ 
standard  use: ids  hail  to  be  convened  to 
meet  I  lie  /.xxxxx  syntax.  1  he  first  set  of 


systems  u\ois  to  be  defined  wete  tun 
1st.)  ihents.  ISO  tisets  wete  chosen 
because  the  vast  majoiity  of  them  ate 
data  processing  piolessionals  and  the 
I  Si)  env itunnient  is  supported  by 
RAO  with  mtiiiM.il  pio.'ificmions. 
Mils  .iiiiili'inentation  w  is  lonoiieiid  in 
a  si'uioth  an. I  professional  mannei. 

i  lie  second  online  system  to  be  imple¬ 
mented  was  the  ROSt'OI  development 
environment.  Since  Ai'/R  iROSC'OI/s 
suppliet)  doe.  not  piuvidt  a  RAfl 
interlace,  oae  hail  to  be  developed 
■nte.it.illv  to  RAtTIb.C'K  usetids  te- 
ipiestinp  a ei  i",,  I  his  K ( XV<  < II.  si^ntm 
mti-y/iur  had  to  be 

ties,  piled  iii  pit'll  ion  toil  so  it  would  win  k 
v-ith  additional  ROSOOli  intei laces 
which  vvonlil  perfurnt  submission  of  jobs 
anil  data-.su- access  validation  services. 

Ati.iin,  the  intpleinentation  of  tins  major 
development  sub-system  was  conducted 
in  a  very  smooth  and  professional  man¬ 
nei  . 

In  conjunction  with  the  implementation 
of  the  ROSC'OH, RACI-  envininmenl,  a 
foiced-signon  policy  was  enacted,  in  es¬ 
se  nee,  out  Company  uses  the  NR1- 
VVORK  I  )l R I  ('  I  OR  pioduet  fiom 
Nonhriilge  Software  which  manages 
VI  AM  network  access.  I  his  pioiluet 
provides  tin  capability  to  teipiite  a  tisei 
to  logon  to  the  system  piior  to  being 
pii'sented  an  applications  menu  which 
contains  the  major  subsystems  to  be  se¬ 
lected  -  i.e.  ROSC'Ob..  I  SO,  etc. 

I  he  N 1 VI  WORK  OIRhC'  I  OR  petfoitns 
RAC'b'  validation  and  properly  inter¬ 
faces  vi'li  all  other  online  subsystems. 
By  requiring  ttseis  to  lop.on  to  the  sys¬ 
tems  ptioi  to  hemp  able  to  make  a  sub¬ 
system  selection.  Access  Ailministi ation 
achieved  a  single  systems  image  view  of 
online  access  requests  —  a  pood  place  to 
be. 

The  l  ist  two  major  subsystems  piovidcd 
intei  ting  challenges.  IBM  s  C'IC'S  has 
a  RAC'b  interface.  However,  since  the 
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Ml  WORK  DIRiClOR  pet  I'm  ms 
RACI  validation  loi  a  11  CICS  users, 
C'K'S  essentially  tclies  on  tills  v;i liil.it ion 
if  ;t  sijMHin- table  defined  user  icqiusts 
access. 

Initially,  Model  2(f4  did  not  have  a 
RACI-  intcifacc.  1  hcrcfoie,  Model  d()  l 
users  were  tcquiied  to  chanj-.e  their 
Model  20-1  p:\sswoids  when  a  RAO- 
passwotd  ch.oq.c  was  pcifoimid.  We 
expect  this  rcquuenient  to  he  eliminated 
with  the  installation  of  the  CCA,  R  ACT 
interface  by  1  all  I ‘>87. 


SYSTI.MS  IN  I  KRI  AC  US  AND 
KNITS 

Once  all  online  system  usets  ate  identi¬ 
fied,  then  all  batch  jobs  e.in.should  be 
piopeily  iilentified.  ISO  nseis  are  au¬ 
tomatically  supplied  appiopi  iate 
usei id; passwotd  paiaineters  at  submit 
time  \  i:t  add t ess  space  atithot  i/ation 
piopapalion  facilities  in  Release  1.7. 
I lowcvei.  a  need  existed  to  inseit  these 
patameteis  in  the  job  caul  of  ROSCOl: 
suhniitied  jobs,  litis  insettion  was  pet- 
fotmeil  by  a  locally  developed  interface 
which  pun  ides 

identification,  notification  set \  ices  foi 
KOSCOf  nseis  stibinittiiij.’.  jobs. 

In  essence,  all  jobs  submitted  to  the  sys¬ 
tem  via  ISO  and.oi  KOSCOI.  ate 
piopeily  identified  with  a  valid  RACI 
user  id  ami  passvvoid.  However,  this  was 
not  n  tie  of  pi  oil  net  ion  jobs  submitted  by 
Computet  Opei.ations, Opei.itions  Sup¬ 
port  .  An  inlei face  had  to  he  locally  de¬ 
veloped  which  would  supply  valid 
piodintion  tiseikls  and  passvvotds  to 
piodlietion  jobs  siihmitted.  I  his  intet- 
I ace  was  locally  developed  anil  supplies 
these  parameters  to  piodlietion  jobs 
basid  on  a  butch  control  inteijnee  table 
which  has  these  paiamclcts  enciypted. 
Since  these  parameters  ate  supplied  dy¬ 
namically  and  available  to  the  system 
only,  the  need  is  satisfied  ami  at  the 
same  time  the  patameteis  ate  not  uni¬ 
versally  lead, tide. 


An  additional  inlet  face  vva.  developed 
winch  piovidcs  RACI  validation  sei- 
v  ices  to  KOSCOI:  nseis 

impoitinp  expoitiii)’.  datasets.  In  es¬ 
sence,  ail  dataset  access  iciptesis  ate 
piopeily  RACI  ll.Ch.cd  piiot  to  I'enie. 
pet  lot  tiled. 

Ol hoi  sysi,  n  intei  f.-ues,  such  as  the 
DMSOS  RACI-  inlet  lace.  vvete 
piuehased. installed  in  oidet  to  ptovide 
appiopi  iate  backup,  iccuvciy  validation. 


PROMT  TION  Ol  OPKRA  I  INC 
SYSTKM  RKSOURCKS 

Opeiatinj;  System  libraties  (S'iSI. 
SVS2.  RUG)  were  subsequently  RACI 
defined  and  pic-tivtcd.  these  hluaiies 
ate  univeisally  lead, able  but  a  RACI 
exception  oceans  when  someone  outside 
of  l.eh  Snppoti  aitetnpts  to  update 

t » k'  mT  i  w  Si  U1  i  v.‘ C s . 

As  pail  of  tins  implementation  phase, 
out  Change  Control  environment  nth / 
< >[irration\  Support  enrironnent  vvete 
subsequently  RACI  pioteeted  in  otdei 
to  pi  event  unauthoi  i/eil  access  to  these 
i  esmu  ccs. 

PROMCHON  Ol  PRODUCTION 
APPI  K  /VHON  SYS  I  I  . MS 


Protection  of  the  Personnel  System 

Oui  I’etsonnel  System  was  the  liist  ap¬ 
plication  system  whose  access  was  con- 
1 1 ollc'il  in  haekpiound  and  foteyionnd 
mode  by  out  RACI  ptoldes.  As  such, 
this  system  scived  as  a  pilot  piojeet 
which  applied  access  contiol  policy  con¬ 
cepts  contained  in  out  then  lecentiy  ap 
pioveil  i'PC-.s4  Iriforniatitm/Dutu 
Seen  city. 

In  oulei  in  fac  ilitate  the  , notes  non  of 
these  resomec's  and  minimi/e  impact, 
RACI  piofiles  vvete  ileliued  in  II  .l/i.Y 
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nimle  ; 1 1 u l  mnmtmeil  lei  appinxmiatels 
one  niuittli.  I  >ni  i  ni-  llns  peiiod,  aeei'ss 
attempts  ill'll'  ICS  idled  .111(1  ICsi'.tu Ill'll . 
Valid  .mess  teipicsis  weie  Mibseip.cnib 
pi  .lull'd  anil  RAC'l  pinliles  isv.e  Hindi  - 
lii'il.  Snbseipieiil  Is .  1 1 n'si'  pinliles  ui'ii' 
mi pli'liicu i i'i*  in  I  .III  Mii'ili'  \\  li n  il  de- 

llil'll  .'ll'l'l'ss  Id  I'll  1 1 1  ICS  Mill  sll'l  1  Ill'll  111  llll' 
pinliles  .'ii'ivss  list.  Tin'  iisiill  nl  this 
iill pli'iili'il t ;i I  ion  Mils  ;i  pinieeled  i'll \ i- 
i  on  incut  Im  tin'  IVisiHiin'l  Sislein 
(SI'I  R)  ivliii'li  .•! Ilow fii  1  Inman  Isi'- 

SlHlIl'l'S  I  Vp.ll  1  lllv'lll  pi'ISIllllll'l  .'ippil'pll- 
;tli’  ;li'i'i".s  In  s\ sli'llls  ii'sulliii's  will li'  ;t! 
tin*  same  linn'  i’\i'l ml i up  lien  aulhmi/i'd 
iisi'is.  I  his  .ii'i'i'ss  in  in.ipi'ini'iit  st i lu¬ 
llin'  pmli'iis  mil  inmp  ins  limn  uii.iii- 
llii'ii/i'il  pi-iii'ti  .ilimis  ami  willful  ami  m 
neeiilemal  ili'sii iii'tinii  of  si'iisiim-  em- 
pm  ali'  ii'i'unls. 

In  .ii'i'milaiii'i'  mill  Cl’il-VI.  Vuv  IV'si- 
di'iil  1 1 1 1 1 1 1 a n  Ri'smn i  t's,  ,n-| i n>;  as  the 
Inlm  nialiml  Ke'snm.V  AilmiiiMi  atm  Im 
llns  system,  was  l In'  appins  inp  emits 
I'm  aeeess  di'linitinn  pinlili's. 

Protection  oj  the  Payroll  System 

t >ti i  I’asmll  S\ si.'in  was  (lie  seemid  ap- 
plieatum  sjsii'in  wliosi'  .'iiii'ss  was  i'mi- 
1 1 nils'll  in  baekpimim!  ami  lini'pinuml 
nimli'  In  mu  RAC'l  emit  mis.  As  siieli, 
llns  ss stein  ini'oi  pin ali'il  pnlu  s  enneepls 
emit. inn'll  in  am  ilien  ii'ii'iilll  appmseil 
C'PCi-.V|  Intoinialinn  Dal.i  Sceniily. 

Apam,  in  nulei  In  taeiln.ile  llie  pm- 
leetimi  cl  these  ii'smnei's  ami  nininni/i' 
iinpael.  RAC'l  pinlili's  wen'  iletineil  in 
if  ,-1/v.V  nimle  ami  inmiilmi'tl  Im  ap- 
pinxiin. ill’ll  mie  nmmli.  Put  inp.  this 
pei  iiui,  aeeess  ailiinpis  wen'  lesieweil 
ami  i eseai elieil.  Valnl  aeei'ss  leipiesis 
weie  snlisi-i) iii'ii i K  pi nnti-il  ami  RAC'l 
pinliles  lieu'  in  ml  1 1  mil .  Subseipienils . 
ilicse  pinliles  sseie  implemenii'il  in 
fill,  modi'  n  Ineli  ilenii'd  aeeess  in  en- 
lilies  nnl  dc  lined  in  l In*  pinlili".  aeeess 
list.  1  he  u'snli  nl  llns  iniplei’ii'iitalinn 
Has  a  pinieeled  ens  iinnnienl  I’m  i lie 


I’.aiinll  Sislein  iilneh  allows 

Aeennniinp  I’as  mil  I  lep.n  linen:  peismi- 
iii'l  appmpn.ile  aeeess  in  sssiems  te- 
siuiiees  is Inle  ai  t In'  same  lime  evluihiip. 
nmi-.inilim i/i'il  useis.  llns  aeeess  ni.m- 
apeinent  stitieime  pinleeis  the  Cump.im, 
li  mu  tm.inllimi/eil  peneii  al  mils  ami 
svil I I'n I  and  m  ieeiileiii.il  desii  neiinn  nl 
sensitise  empoi.ile  leenuls. 

In  aiemilanee  svitli  C  PCi-.V|,  Man.ipei 
(ieneial  Accmiiiiiii'.  act  inp  as  lite  1  n - 
Im  in.it  inn  Resmiis  Adminisli  aim  Im 
this  sislein.  sv.,s  the  apptoMtlp.  eillilill 
lin  ,'ieees  ilelinilimi  pinliles. 

Protection  of  the  Customer  F.nrironment 

s)ni  C'nsinmei  Setsiees  Sislein  (CSSR) 
snppnits  the  C'nslniiii’i  Seisin's  and  Ac- 
emininip  I  >epai  tments.  Inl'mm.ilinn 
pins  nli'il  I'i  this  si, stem  is  s  it.il  in  l lie 
business  liinetiiiiis  nl'  mil  eninpans.  I  n 
Mil  inp.  l lie  imepiils  ami  ennlinl  nl  llns 
ilala  1 1 ii'i el'ni e  is  silal  tn  das-ln-ilus 
C'empans  npei annus. 

In  nulei  In  facilitate  the  p'nli'elmn  nl' 
ensinniei  seism's  lesmnees  anil  mini 
mi/e  impaei.  RAC'l  pinliles  weie  de¬ 
fined  in  Hi  I  At.  V  inmle  and  ninniimeil 
Im  appinxini. nels  mu'  inniilh.  Ptninp. 
llns  peinul,  aeei'ss  allempls  sseie  io- 
siessed  ami  teseaielied.  Valid  aeeess  ie- 
ipiesis  sseie  subsequent  Is  p.ianied  and 
RAC'l  pinl'les  sseie  muddied.  Stibse- 
ipii'nils,  iliese  pinliles  sseie  implemented 
in  /  All  nimle  which  denied  aeei'ss  in 
fill  mi's  nnt  delined  in  the  pieliks  aeeess 
list.  I  he  tesiill  nl  this  implenu'nlalimi 
ssas  a  pinieeled  ens  iinmnent  Ini  the 
C'usinnu'i  Sen  lees  and  Accemitinp  ile- 
p.n  iments. 

In  aeeuiilaiiei'  ssilli  C  l’Ci-31,  Diieelm 
C'uslnuii'i  Sets  tees  ami  M.mapei  Cien- 
ei.il  Aeeminlinp  ailinp.  a'.  I  lie  Infnima- 
t inn  Resnmee  Ailmiiusiiaims  fm  these 
s\ stems,  weie  the  appiosinp  eniuiiy  tin 

aeeess  tie!  mil  inn  i  u les. 


<;i:m:ki<  i*koi  ii.i  s 

All  RACI  piollk's  doliliod  tl  II 1  III!'  1 1ll'' 
imploniontatimi  uoio  (il.XPRIC  inm- 
doi  lo  niitiniu/o  losomoo  oonsiimpiioii. 

I  AC  KI’I  ION  Ri:i*OR  I  IN(; 
systims 

C  >u  i  Exception  Keportiny  Sy\tcm  ( I.RS) 
lopmls  \  j i > I ; 1 1  inns  .lint  aoooss  to  RACI 
doliliod  Ii'vhikvs.  1  lioso  lopoits  .no  os- 
sontial  iii  I n i t >i in .i i u>n  Sxsionis  Aoooss 
Adininisii :it mn  sjnoo  iliox  oonstituto  mu 
piiin.nx  muiioo  ol  .looms  inlm iii.ninii 
amt  pioxido  inl'oi  mat  ion  i'ii  tin*  oltoo- 
lixonoss  ol  RACI  pmioolion  ol't'oipo 
i.iio  Inl'oi  Mi  nion  Sxsionis  losouiox-s. 
P.iih  1  \oopnon  Ropi'i  imp.  Sworn 
(I  RS)  i imslio.ims  oxoouto  SAS  pio- 
pi anis  wliioli  xoan  SMI  Pula  pioduood 
in  i In-  M  VS  X A  sxstom.  I  lioso  pio- 
pi.inis  lopoil  RAt'l  SMI  looonls  ao- 
1 1 \  i ! \  and  Minimal  i/o  inl'oi  inalinn 
pi o\  idod  In  ill  RAt  I  Roj-.o.i  l  W  i  iii* 
(RACI  R\\  )  I  ho  ooitsolid.uod  oxoop- 
t ion  iopoiis  doiail  aoooss  oxooptiom  and 
soouiiix  xiolaiiom  wliioli  aio  loxiouod 
dailx  and  nnoiol'ioliod. 

Pailx  I  \ooplioii  Ropoilmj’.  S\ -•loin 
(I  RS)  iiinstioani  in  t In*  VM  SI’  oini- 
t on nii-n I  poiloini  a  miiiiImi  lnnoiion  In' 
soaiiniiii'.  VM  data  pioduood  In  llio 
VM  SI’  MOOiHinliiij'  sxsloin,  and  piodno- 
iup  ropmls  wliioli  liij’.lihp.lil  VM  SI’  io- 
ooids  aolixily.  1  iion  lopoiis  aio 
loxiouod  d.nh  and  nuoiofioliod. 

On i  xxooklx  synolnnni/ation  i uiMio.im 
load  i ho  M.’lh  poisnniiol  d.iialviso  and 
oompaio  ils  oonlonls  with  i ho  RACI- 
ilalahaso  piolilos.  I  )ifloionoos  aio  10- 
poiiod  I'm  linilioi  aolion  In  I  n  I'm  in  a  t  ion 
Sxsionis  Aoooxx  AdminiMiaiion. 

Profile  Synchronization 

I’looodmos  mod  lo  loipiost  pianl  aoooss 
lo  Inlm  mat  ion  Rosmiuvs  (soo  CI’ti-3-l) 
loipiiio  inainloiiaiioo  and  updalo  in  a 


xaivtx  of  sxsionis.  Mmi.  Inn  noi  all  of 
1 1 1  oio  sxmoiiis,  aio  ni.inapoi!  In  oin  Ao¬ 
ooss  t'oimnl  I  aoililx  (HIM  S  RACI  ). 
Iloxxoxoi.  a  iopooioi\  of  inlm  in. iiion 
iiidioalino  all  aoooss  —  inolndmp 
non  RAt'l  siioll  as  W.ilkci  Intoi.ulixo 
aoooss.  M  ’0  1  aoooss  olo.  —  is  ioi|iiitod. 
As  a  nsiill,  a  R  It  7  /  uti  l>ntill'n\e 

.S|i  to///  (RIPS)  \i  as  iloxolopod  Rl'DS 
is  a  S  \S  I  'Cl  I  SCRI  I  N  I’ROPCCI 
appho.iiinii  v, lii.  li  is  usod  In  Inl’oi  in. i 
lion  Sxsionis  Aoooss  Adniinisli aioi  lo 
liuok  lox ols  o|  aoooss  uianlx'd  lo  all 
RACI  ilolmod  mois.  I  owls  of  aoooss 
pianiod  molndo  tICS  soouiiix  ko\s. 
RtlSCOI  .  ISO.  and  M.’OI  oa pal'ili! ios 
and  oilioi  aoooss  anilioi  ilios.  Rl'OS  io- 
oonls  aio  npd.nod  In  t Iso  RACI  Ad- 
miiiisii.ini!  as  aoooss  .iiiiImi  i/.iiioii 
I'm  ms  aio  pmoossod.  I  Ho  Ml .1  ill  ohjooliw 
of  Rl'OS  is  In  have  a  iviitinl  n'/'o/'i'/r 
ihul  i  i///  he  inn/  ./'  •/  icjeicnee  point  hy 
hifi» iiiiiHnn  Si  i/o"/'  .-I in  i'  Ailniuu'- 
Ii.ilnin  nil. I  Intertill I  InJit. 

Summary 

Wo  l>olio\o  i ho  imploniont.uioii  of  oin 
dal. i  soiii ills  p.iok.apo  (RACI  )  lias  Ivon 
a  snoooss  Ivoaiiso  il  midi ossod  aoooss 
ooniiols  ai  a  om potato  lo\ol  liisi  and 
sooond.ailx  al  a  uchnioal  lo\ol.  As  a 
i osuli .  wo  1 1 .' i \ o  lod.n  a  Cmpmato  I’olux 
on  Inl’oi m. moil  Oaia  Soimin.  loipiosi 
pioooduios.  and  loohnioal  oap.il’ihiios 
wliioli  dnooi  and  ooniiol  ilio  oompain  s 
inlm  in. 1 1 ion  losmnoos  and  man. loo  ao¬ 
ooss  lOipiosis  and  piofilos  inodifioalious. 

I  lioso  achiowmoiiis  aio  h ip‘ h i is* li t oil  In 
RACI  pi oiootoxl  sxsionis  and  applioa- 
i ion  onMionnioiils.  snoli  as  P.nioll.  Iln- 
man  Rosomoos,  and  Cmimnoi  Soixioos 
xxlioio  appiopiiato  aoooss  lo  sxsionis  io- 
souioos  is  pianiod  lo  lop  it iniaio  usois 
xxlnlo  al  I  ho  saint  timo  oxolndinp  non- 
auilioi  i/oil  usois.  "1  his  aoooss  niaiiapo- 
nionl  snuoliiio  pioioois  om  oouipanx 
limn  n  n  a  in  tim  i/OiI  ponoualions  ami 
willful  and  oi  aooidonial  dosiiuoimn  of 
sousimo  ompmaio  looonls. 


MANAGEMENT  ACTIONS  I* OH  IMPROVING  Dob  COMPUTER  SECURITY 
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A  common  perception  in  tlu-  Dob  is 
that  system  high  operation  is  the  normal 
current,  security  mode  of  operation.  Much 
attention  is  now  fv>oused  on  ways  to 
a  .1  vs  nee  beyond  ay  at  err.  hip,  h  opera  t  ion  into 
multi  level  r.eeur*e  (MLS)  operat  ion.  From 
the  field,  however,  comes  a  different 
view.  In  fact,  the  vast  majority  of 
systems  still  operate  in  the  dedicated 
security  mode  of  operation.  This  does  not 
necessarily  reflect  no pat  ively  on  PoP 
security.  Father,  it  is  an  import. ant 
aspect-  of  PoD  computer  security  that  needs 
t.  o  be  um  d  or  a  l  ood  . 

A  second  aspect,  of  current  practice 
is  occasional  ineffective  use  of  computer 
security  safeguards.  While  there  has  been 
no  recent  definite  ve  review  of  Pop  com¬ 
puter  security  practice,  there  are  cases 
of  systems  in  which: 


•This  paper  is  derived  from  work  per¬ 
formed  under  contract  F 1 9  o  2 ii - 8  u - C - 0  0  0  1 
for'  the  United  States  Army,  Europe 
(USA  RE  UR),  Office  of  the  Deputy  Chief 
of  Staff,  Operations  (ODCSOP3). 


*  Group  passwords  are  used. 

*  Passwords  are  not  often  changed  and 
are  not  well  prelected, 

Audjt  t ra i ) s  are  not  checked  or 
even  kepi  . 

*  File  protect  ion  foil  a  res  are  used 
liaph  i.*.  it'd  1  y  or  not  at  all. 

*  copy  command:;  are  trusted  to  Copy 
unclassified  files  from  classified 
disks  to  unclassified  di-.ks. 

Some  system.;  are  operat  i  ng  without  having 
bem  ae»?  red  »  t  ed  .  One  report  addressing 
coinput  i'r  use  by  Defen:;e  eont  met  r>rs 
lists  opoc.-it  i  on  without  ac  c  rou  i  t  a  t  i  on  as 
the  most  common  deficiency,  and  notes  that 
tin.'  finding  is  probably  equally  applicable 
tv'  government  computer:*  .  oome  systems 
have  not  been  certified  by  any  systematic 
process,  other  than  the  implicit  cert  if i- 
eation  that  conn's  from  operational  use. 

Ueeasiona:  eases  are  riv>t  sufficient 
cause  for  alarm,  and  do  not  imply  inade¬ 
quate  protection  of  classified  infor¬ 
mal  ion.  Nevept.he  1  ess  ,  prude  nee  suggests 
tl»*'  need  for  closer  examination  of  the 
c  u  r  r  en  t  situation. 

It  j s  important  t  o  recognize  that  MLS 
technology  doe:;  not  address  these  matters. 
Indeed,  the  insertion  of  Ml.S  technology 
into  this  envi  ronm*'nt  eon  Id  create  a 
problem.  In  a  dedicated  mode  system, 
whatever  human  error:;  are  made,  the  person 
who  ends  up  seeing  the  data  is  still  fully 
cleared  and  authorized.  This  is  true 
because,  by  definition,  all  users  of  a 
dedicated  inode  system  must  be  cleared  and 
authorized  for  all  dat  a  in  t  lie  system.  In 
an  MLS  system,  often  there  is  no  longer 
such  protection  against  human  error1.  If  a 
‘sor  aeoi  dent  ally  labels  Secret  data  a:; 
unclassified,  uncleared  users  might  be 
able  to  access  the  data.  Fu  r  t  tier  more  , 
some  user’ a  tend  t. o  view  MLS  produets  as 
magic,  plug**i:i  solul  ions.  They  are  some¬ 
times  surprised  to  learn  that  t  lie  sc  p:  o- 
d  ue  Is  need  tv>  be  adapted  for  their 
specific  applications.  If  users  do  t  h  i  s 
adaptation  themselves,  it  is  possible  that 
in  doing  so  they  will  unwittingly  subvert 
some  of  the  protective  features  of  the 
p  r  o  d  iu  t. . 

Technology  alone  cannot  bo  relied  on 
to  satisfy  the  security  needs  of  most  Dob 
users.  Technology  is  merely  one  clement, 
in  a  set  o:  safeguards,  of  which  the  most 
important  element  continues  to  be  user' 


pract  ice.  JU’I'orc  t  retinol  eg  i  e*»  1  sa  fog  nurd  s 
0‘in  be  1  M  :.  I’p  ted  into  an  v  n  v  i  roniin'ii  t  ,  their 
imj-ieta  must  l  c  examined  in  the  context  of 
pa  t  ami  n  n t  1  e  i  p  i  t  od  user  nerds  atni  pr.ie- 
t.  i  on. 

St),  but  li  to  l"’ l  ter  in  ui  ei'o  t  .i  nd  our 
eu  i*  re  11 1  r*o  tju  t  reiiir  n  t  s  and  Lo  better  employ 
U'ohnoloKii’a  l  i  mpioveinerit  s  ,  it  i  s 
de  s  i  rib  1  e  ho  conduct  a  eloiscr  ex  run  i  nation 
of  current  practices.  Tin*  next  sect  ion 
provides  tin*  first  step  toward:*,  such  an 
exam i nu  t  ion. 

Tin:  WOULD  ACfQHlM  NO  TO  USKHS 

Ac  noted  above,  two  key  factor:; 
cli.irac  \  er  i  •/.  e  the  rnv  i  ronincnl  ol*  many  bob 
computer  u net's: 

*  Dedicated  .node  philosophy 

*  Occasional  ineffective  use  of  e o in¬ 
put  t  r  security  :.a  fcgu.’.rd:* 

Probably  t  h «'  main  reason  so  many  DoP 
computer  syst  cm  a  operate  in  the  dedicated 
mode  i  r.  that  that  i  how  tin*  manual  system 
operated  before  the  eemput.er  war.  intro¬ 
duced.  Much  of  the  Dob  lias  a  dedicated 
mode  philosophy.  In  financial  systems, 
separation  of  duties  and  knowledge  :i»c 
usually  considered  to  he  the  nu»:;t  impor¬ 
tant  security  principles,  and  tin*  compart - 
mental  ion  of  knowledge  pi* .act  iced  by 
terrorist  cells  is  well  known.  The  hob 
due;;  fellow  this  principle,  lull  the  cells 
sometimes  t.end  to  be  large.  Dob  security 
policy  strongly  advocates  the  importance 
of  need -t  o-k  now  :;ep.i  i*a  l  i  oti  .  For  example. 
Army  Herniation  (AH)  3dd-3''D  states  that 
"a  serious  violation  potential  exists  if 
all  users  are  authorized  access  to  all 
dala,,l>.  Sometimes  this  emphasis  is  not 
well  reflected  in  the  way  mission  re¬ 
sponsibilities  and  knowledge  at1;'  part  i- 
t  dom'd  and  assigned,  however. 

This  lack  of  mission-driven  emphasis 
on  yeparat  ion  of  duties  and  knowledge  is* 
un  fort  unat  e  ,  because  eomputers  change  the 
mission  equation  and  can  increase  t  lie 
r  i  skf.  invol  vod  : 

*  An  office  of  fO  people  mi  g  tit 

r  e  a  s  o  n  a  b  1  y  e  in  p  1  o  y  a  d  e  d  i  c  a  t  r  d 
mode  philosophy  for  most  of  its 
work  .  A  computer  network  of  bOO 
prop  le  eu  tmo  t  . 

*  It  takes  awhile  and  might  appear 
suspicious,  to  reproduce  a  large 

e  1  a  •;  s  i  f  i  o  d  d  o  c  u  me  n  t  o  n  a  c  o  p  y  i  n  g 
machine,  bisks  can  In*  copied 
quickly  and  without  attracting 
undue  attention.  Disk  contents 
can  hr  quickly  and  easily  trans¬ 
mitted  any where  in  the  world 
using  equipment  commonly  found  in 
homes  . 

Often  dedicated  mode  is.  unq  ura  t.  i  on  - 
ably  the  correct  operating  inode.  This  is 
Lho  case  for  many  personal  computers  and 


for  systems  that  truly  have  no  require¬ 
ments  for  need  - t  o -k now  30p.irjt.ivn.  Where 
dedicated  i-  ode  is  a  p  p  r  o  p  i*  i  a  t  e  ,  it  can 
offer  advantages.  For  example,  in  a  de¬ 
dicated  mod;*  system  t  lie  re  j  s  no  need  to 
manage  security  access  tables  that.  If 
impi’opcrly  managed,  can  deny  access  to 
an  t  ho r  i  /.  ed  u  sc  r  s  . 

On  l  lie  other  hmd,  with  the 
increasing  amount  o !’  information  being 
stored  in  computers  and  the  increasing 
number  of  users  being  grant ed  access 
t  hi'oii  *h  networks,  dedicated  mode  operation 
is  becoming  more  risky.  The  mahagmit  ut 
challenge  is  to  recognize  when  dedicated 
incite  is  appropriate  and  when  it.  is  not  . 

The  point  of  this  paper  is  not  that  dedi¬ 
cated  inode  opera!  ion  is  inherently 
desir-ible  or  undesirable,  but  that  the 
decision  must  he  made  wisely. 

The  second  fn*t  di  char  ae  t  e  r  i  v*.  j  ng  the 
environment,  of  many  Dob  computer  users  is 
occa  s  ton  a  1  ineffective  use  of  computer 
security  safeguards.  Perhaps  t ho  one 
thing  worse  than  inadequate  security  is  to 
have  inadequate  security  n  n  .1  not  realize 
it..  Computers  can  ci  ■  n  \  r  i  bu  l  i.  to  this 
misapprehension,  because  it  is  easy  to 
forget  that  computer  security  is  dependent 
on  Llit'  people  who  use  and  administer  the 
computer.  The  discussion  earlier  in  this 
paper  notes  the  existence  of  oases  in 
wlii  eli  sa  fogiiar.i  s  are  not  used  or  arc  used 
i  siipropei*  1  y  .  This  is  an  aspect  of  bob  com¬ 
puter  misuse  tii.it  cannot  he  ignored  or 
.assumed  away. 

When*  sa  feg.ua  id  s  are  not  effectively 
used,  reason:*  include  the  following,:  (1) 

people  make  errors  and  take  Shortcuts,  (  .** ) 
people  have  in'*!  b  .on  adequately  t  paint'd  to 
use  the  sa  f  egua  r.i  s  ,  (3)  people  do  not 

appreciate  the  importance  of  computer 
security  safeguards,  (  '»  )  security  res.  a  tir¬ 
oes  are  insufficient  ,  and  ( h )  technic  il 
computer  security  safeguards  can  be 
penetrated.  .Several  words,  of  explanation 
are  warranted  h'  illustrate  why  insuf¬ 
ficient  security  resource::  can  lead  to 
i reflect  ive  use  of  safeguards. 

Whereas  industry  i  a  free  t.  o  grow,  tin* 
bob  i  •;  not.  In  the  bob ,  it  is  easier  to 
buy  an  additional  computer  than  it  is  to 
hire  in  a-ldilional  person.  One  argument 
for  buying  computers  lias  been  that  they 
reduce  the  number  of  people  needed. 

Un for t uni  l el y ,  some  bob  offices  purchase 
computers  only  to  discover  tint  the  oppo¬ 
site  is  oft. en  true.  1  a  the  security  area, 
policy  (r.£.,  AH  3-10-3:1 0  ,  1  )  6  \> )  stales  the 

need  for  additional  security  resources  by 
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People  a:**3  t  j'linl  Uir.io  ml  os  are  reaputi- 
s  t  1'  i  e  for  nm’li  tasks  as  os  t  a b i  l  sh  i  iik  and 
in:*  i  Ml  a  i  u  i  n*-;  security  d a  V  a b a  s  e  s  ( c  .  f>  ■  »  user 
c  1  I’.'ii'.'liu'i’:;  f  pjr.nwordy  ,  and  a  occur-  capabi¬ 
lities;  facility  security  profile:*)  and 
nia  i  »it  a  i  n  i  no  and  rev  i  ow  i  nr.  sy  s  t  *% :t:  and  i  k 
i  :i  format  ion.  Tlir  problem  In  lli.il  there 
roler  arr  a  1  moat  always  a  a  a  I  p,  ihm  a  a  addi- 
t  ionil  -jut  ion  ant  l  1 1  it  the  people  ana  itfticd 
the  i*o  lea  no  me  l  i  men  hive  i  1 1  :•  u  f  f  i  e  l  r  u  \ 
l  no  i'ii  t  i  vr  o  ,  tii.e,  and  training,  to  fulfill 
l  hr  m.  The  impael  in  that  computer 
security  :=;i  f  ep.u  i  r  d  a  can  l  «:  conic  ineftec- 
t  i  v  e  . 

WIuti'  the  uae  el  internal  oonputrr 
security  sa  !  e-'n  i  rd  s  in  i  nef  f  eel  i  ve  ,  l  In* 
opt  i  on  a  are  either  t  u  use  l  lie  a  a  f  e«;iin  i  d  a 
i:uife  e  fleet  ively  tit*  to  place  loan  rel  iauee 
on  them.  The  ina  na  r.e  me  n  t  challenge  ia  to 
decide  wlijeh  option  is  appropriate.  In 
many  can's,  tin*  latter  approach  ia  chosen 
and  the  :iyat  em  ia  operated  in  dedicated 
mode.  There  art*  many  care:;,  however,  when 
disl  itMt  i’d  mod  e  ope  r  a  t  i  on  will  no  i  suffice. 
Kur  l  net  more  ,  even  w  i  t  n  dedicated,  mode 
o  p  e  r  a  t  i  on  ,  in  my  inl'onnat  ion  ,  p  or  a  on  a  e  1  , 
physical,  Oemmun  t  e  * 1  inns,  and  omanal  ions 
ih'iMiri  t  y  s.ifo^u.irjs  are  needed.  The 
r'cmainler  of  this*  paper  presents  maiiap.e- 
mfiit  actions  for  improving  bob  security  in 
1  i  t\U\  of  the  uit'i*  environment  described 
a b eve  . 
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arc  r  edit-  of  a,  find  sometime.**  the  users  an 
vie]  1  )  .  Sonn*  bolt  personnel  still  d>>  not 
know  th.it  there  is  more  to  computer 
security  than  Thrift.  ST.  They  do  noi 
understand  the  difference  between  dedi¬ 
cated  and  sy3tcni  hif.h  mode.  Some  who  know 
a  little  atuJt-  security  think  that  the 
problems  will  be*  solved  by  end  -  to- end 
encrypt  i  o  n  .  Others  who  Ii  iv  h  e  1 1  d  about 
the  Oraup.e  houk  kn«'w  nuthiriK  -iluiul  the 

advant.ie.es  of  volatile  n;  emery  or  mimv  j- 
b  1  c  ha  ril  d  i  sk  s  ^  . 

Till:*.  1  i  ’  k  of  know  1  edp.e  could  p,  i  v  e 
ri.it>  to  problems.  For  example,  vglat  i  1  -* 
memory  and  removable  hard  disks  ear  pro¬ 
vide  a  periods  process  i  up.  capability  (to 
alternate  operation  between  multiple 
security  levels)  a ad  can  simplify  physical 
security  requirements  for  the  d.it  i  (since 
the  disks  can  be  locked  in  salt'.".).  If 
procnr  *  men  t  s  i rue  re  these  feature:*,  some 
ust.Ts  m  ip,  lit  find  it  difficult  to  s  at  i  sly 
their  security  requirement:*. 

The  key  t o  a  successful  computer 
mrui*  i  t  y  training  |m  >>gt*.i[ii  i  to  i  n  e  1  u  d  •• 
c  v)  m  pit  t  e  r  security  t  raiuinp  a.*  in  integral 
part  of'  both  mis:*  i  on  and  system  Iriiniup . 
Tli  is  tra  iii  trip  will  have  to  overcome  t  lie 
skepticism  that  Some  people  feel  towards 
e*Miipnter  security  requirements,  which 
defend  apaiiml  t  lire  its  that  the  people  »1  e> 
net  consider  i  p.a  i  f  i  •*  an  t  .  To  overcome 
this  skopt  iclsin,  tea  ini  up  Should  present 
convincing  examples  of  why  compul  cr 
;V  :s  »•  j  •  '■  •*  a  f  e  e  a  .■  r ,! :;  are  need:'*.  Tb. 
oxnnpjes  should  involve  easily  a  n  d  e  rs  l  oo  d 
threats  such  as  human  error,  rather  than 
arcane  threats,  such  as.  Trojan  horses  or 
con  I  i n  e men t  c  h a  n  u  e 1 s  . 

I’l.'r.-oinu’l  turnover  in  the  bob  l  s 
hip.li,  due  t  frequent  relo.  at  ions.  Tliere 
is  a  eon  t  i  n  ii  i  up  n»*i.*d  to  quickly  train  n**w 
us.ers.  To  accomplish  this,  Oeinpiit  n’ 
security  fund  »inen  t  a  1  a  should  he  stressed 
duririp,  system  f  am  i  1  i  a  r  i  ,’.a  t  ion  and  opera¬ 
tion.  For  example,  before  heinp,  printed 
inil.  i:il  access  to  a  system,  new  users 
should  rcocive  a  computer  security 
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1  understand  that  floppy  disks  may 
not  tie  removed  from  the  secure 
area  . 


’  I  understand  the  Red/Black  separa¬ 
tion  requirements  for  t.he  system. 
(Simple  Bed /Black  separation  guide¬ 
lines  were  recently  declassified, 
and  should  be  posted  near  the 
system . ) 

More  widespread  emphasis,  on  such  simple 
rules  would  improve  computer  security 
practice  in  the  DoD,  especially  in  those 
situations  where  users  must  begin  using  a 
system  without  first  having  had  any  formal 
training.  Users  cannot  be  expected  to 
know  the  prodigous  number  of  rules  that 
constitute  DoD  computer  security  policy. 
Therefore,  emphasis  should  be  placed  on 
those  few  rules  that  counter  the  major 
risks  . 


The  second  management  action  fun¬ 
damental  to  improving  DoD  computer 
security  is  improved  field  support.  The 
day-to-day  computer  security  war  is  being 
fought  in  the  field.  Yet,  with  the 
increasing  number  of  computers  being 
introduced  into  the  DoD,  the  people  in  the 
field  are  fighting  a  difficult  battle  arid 
need  reinforcements. 

The  key  people  in  the  field  are  t. he 
computer  security  managers  assigned 
throughout  the  DoD.  Their  role  is  to 
oversee  the  implementation  of  policy. 
Unfortunately,  the  staffing  of  these  offi¬ 
ces  has  not  increased  commensurate  with 
the  increased  number  of  computers  being 
used  for  classified  processing.  Some 
Major  Commando  with  thousands  of 
classified  systems  have  only  one  person 
assigned  to  oversee  computer  security. 

An  important  part  of  a  computer 
security  manager's  job  is  to  coordinate 
■system  accreditations.  Their  review  of 
accreditation  packages  is  often  the  only 
independent  examination  of  a  system's 
security.  Yet  some  computer  security 
managers  do  not  have  the  training  or 
resources  to  do  their  job.  Since  these 
people  could  not  begin  to  do  the  larger 
job  of  system  certification,  typically 
system  buyers,  developers,  and  integrators 
ars  relied  upon  to  evaluate  '  o  i  r  own 
work  . 


The  result  is  that  every  year  some 
DoD  computers  are  placed  into  operation 
without  adequate  security  oversight.  Some 
systems  are  operating  with  no  accredita¬ 
tion  at  all.  The  accreditation  process  is 
definitely  not  a  meaningless  paper  pro¬ 
cess.  Computer  security  managers  of  ter, 
find  problems  during  their  accreditation 
review,  and  system  security  is  usually  im¬ 
proved  through  preparation  of  an  accredi¬ 
tation  request.  The:  accreditation  process 
might  benefit  from  some  streamlining,  but 
it  is  an  essential  process  nonetheless. 


Several  step:,  can  be  L  a  k  e  n  to  i  m  p  r  o  v  e 
tile  plight  of  computer  security  managers: 

*  Ensure  that  all  system  planners 
are  trained  in  computer’  _>ceurity 
and  tli at  they  know  to  consult  with 
comput.  or  security  personnel  early 
ir.  the  system  planning  process. 

If  more  systems  follow  the  rules, 
the  job  of  enforcing  the  rules 
becomes  easier. 


Increase  the  staffing  of 
put.er  security  offices, 
be  a  difficult  step,  but 
neces:. ary  one. 


field  com- 
This  will 
it  is  a 


"  Ensure  that  computer  security 

managers  are  adequately  trained, 
and  give  them  frequent,  oppor¬ 
tunities  to  update  their  training. 

•  Give  computer  security  managers 
the  rank  and  recognition  their 
position  warrants.  Support  them 
in  taking  punitive  action  against 
systems  that  operate  without 
accreditation  or  that  do  not  com¬ 
ply  with  approved  approaches. 

Some  of  these  improvements  in 
training  and  field  support  will  be  dif¬ 
ficult  to  implement-,  but  efforts  must, 
begin.  There  is  a  final  r  ecommer,  da  t  i  or. 
that  is  easier  to  implement  and  that 
should  produce  near-term  improvements: 
the  National  Computer  Security  Center 
(NiSC)  should  expand  upon  its  continuing 
assistance  to  field  support  personnel. 

The  NCSC  is  already  providing  substantial 
assistance  to  the  field  via  such  means  as 
travelling  training  teams.  The  NCSC  could 
provide  further  assistance,  however,  by: 

’  Conducting  3  six-month  study  of 
field  computer  security  management, 
offices  to  determine  (1)  the  state 
of  computer  security  i n  the  field, 
and  ( 2  )  what  field  comput er 
security  managers  believe  is 
needed  (by  both  themselves  in 
particular  and  the  DoD  in  general) 
to  improve  DoD  computer  security. 


Sponsoring  the  development  of 
additional  simple  management  and 
training  tools  to  improve  computer 
security  practice.  (The  NC3C  his 
already  made  some  useful  contri¬ 
butions  in  this  area,  such  as  a 
one-page  summary  of  personal  com¬ 
puter  security  rules.) 

Encouraging  field  computer 
security  management  people  to 
attend  annual  NCSC  conferences  in 
order  to  meet  eacli  other  and  to 
present  their  views  and  exper¬ 
iences. 


Just  as  field  personnel  can  benefit  Trom 
NCSC  knowledge,  so  can  NCSC  personnel 
benefit  from  field  experience. 
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CONCLUSIONS 


A  brief  examination  of  user  environ¬ 
ments  in  the  field  shows  that: 

*  Dedicated  mode  operation  is  the 
most  common  mode. 

'  There  is  occasional  ineffective 
U3e  of  computer  security  safe¬ 
guards. 

These  findings  suggest  the  need  for  a  more 
thorough  study  of  the  state  of  computer 
security  in  the  field.  Furthermore,  the 
findings  must  be  taken  into  consideration 
before  new  policies  or  technologies  are 
applied  in  the  field.  In  some  eases  the 
findings  represent  problems  that  can 
readily  be  solved,  but  in  other  cases  they 
might  represent  fundamental  environmental 
limitations  on  what  is  achievable.  System 
managers  must  be  able  to  distinguish  these 
cases.  Technological  improvements  can  he 
harmful  if  they  result  in  a  false  sense  of 
security. 

DoD  computer  security  can  benefit 
greatly  from  improvements  in  training  and 
field  support,  which  would  help  us  to 
better  manage  and  use  systems.  DoD  per¬ 
sonnel  at  all  levels  should  be  made  more 
informed  about  computer  security,  and  com¬ 
puter  security  managers  in  the  field 
should  be  given  the  resources  they  need  to 
do  their  job.  Nuw  that  an  improved  foun¬ 
dation  of  computer  security  policy  and 
technology  has  been  e;tablished  in  the 
DoD,  more  attention  should  be  placed  on 
ways  to  improve  practices  in  the  field. 

ACKNOWLEDGE  NT 

The  author  is  grateful  for  the  review 
and  comments  provided  by  LTC  L.  Stefl'enscn 
of  Headquarters,  USAREUR. 


REFERENCES 

Ill  DoDSI  No.  5-86  (September  198b), 
"ADP  Security  Deficiencies," 

Security  Awareness _ Bu  1^1  e_t  i£i ,  DoD 

Security  Institute. 

£ f? I  AR  380-380  (8  March  1985),  Automa¬ 
tion  Security . 

|3]  DoD  3  2  00,28 -ST D  (December  198b), 

Department  of  Defense  Tru3t ed  Com - 
putcr  System  Evaluation _ Criteria  . 


102 


BISK  ANALYSIS  AND  MANAGEMENT 
IN  PRACTICE  FOR  THE  UK  GOVERNMENT 

THE  CCTA  RISK  ANALYSIS  AND  MANAGEMENT  METHODOLOGY:  CRAMM 


Mr*  Robin  H  Moses  -  UK  Central  Computer 
and  Telecommunications  Agency  (CCTA) 
Hiverwalk  House,  137-161  Mi  11  bank, 

London,  SW1P  llHTf  England 

Mr  Rodney  Clark  -  BIS  App)  ieci  Systems  Ltd  , 
?0  Upper  Ground,  London,  SE1  9PN,  England 


INTRODUCTION 

1  .  The  paper  describes  a  risk  (analysis  and) 
management  methodology  for  Information  Technology 
(IT)  Security  developed  by  the  UK  Government 
Central  Computer  and  Telecommunications  Agency 
(CCTA)  of  Her  Majesty's  Treasury,  with  the 
assistance  of  BIS  Applied  Systems  Limited,  The  T.T 
Security  and  Privacy  Group  of  CCTA  is  the  National 
Authority  for  advising  British  Government 
Departments  on  all  aspects  of  the  protection  of  IT 
Systems  handling  unclassified  but  sensitive  data. 
The  methodology,  designed  for  the  identification 
of  justified  security  measures  for  both  current  and 
future  IT  systems  processing  Government  sensitive 
dat-i,  has  -  as.  cf  May  198?  -  successfully  been  the 
subject  of  five  separate  trials  with  systems  of 
different  environments.  An  automated  support  tool 
is  now  being  produced,  and  comprehensive  training 
in  use  of  the  methodology  by  non  experts  is  being 
prepared . 

EXTENT  OK  THE  PROBLEM 


THREATS  VULNERABILITIES  ASSETS 


RISKS 


COUNTERMEASURES 


T 


ANALYSIS 


MANAGEMENT 

A. 


and  incorporating  related  ‘sub-components1  such  as 
frequency  and  severity  of  threats,  impacts  and 
countermeasure  costs. 

HMG  APPROACH 

3.  As  a  National  IT  Security  Authority  for 
Government  Departments,  CCTA  was  invited  to  mount, 
and  manage  a  project  to  identify  or  develop  a  risk 
management  methodology  which  would  meet  thirteen 
mandatory  requirements.  These  irxludcd:- 


?.  Her  Majesty’s  Government  (HMG)  Departments 
have  recognised  the  general  concepts  of  rink 
management  for  some  time  and  implemented  them  in  a 
pragmatic  and  relatively  subjective  manner. 

However,  by  rnid  19^3  both  Departments  and  the 
Government.  Security  Authorities  identified  the  need 
to  develop  a  unified  approach  to  risk  management 
which  was  threat  rather  than  vulnerobi 1 i ty  driven 
and  which  could  be  applied  across  the  wide  range 
of  HMG  system  types  to  identify  more  accurately 
necessary  countermeasures ,  provide  justi fixation 
for  spend  and  be  understandable  to  non-techmcal  iy 
expert  general  managers •  With  the  rapid  expansion 
of  IT  and  the  high  cost  of  development  of  some 
secure  systems  it  was  not  considered  to  be  viable 
to  continue  with  a  significant  probability  of 
unjustified  spend  on  security  and/or  without  high 
confidence  that  all  justified  countermeasures  had 
been  identified.  It  was  also  recognised  that  the 
approach  would  need  to  cope  with  the  complex 
situations  where  many  throats  could  impact  more 
than  one  asset,  many  countermeasures  could  counter 
more  than  one  threat,  and  many  countermeasures  could 
protect  more  than  one  asset.  It  was  agreed  that 
risk  management  should  be  put  on  a  much  more  formal 
and  structured  basis  to  deal  with  these  problems, 
using  as  a  basepoint  the  rosin  components  of  risk 
analysis  and  management  as  shown  on  the  traditional 
simple  model 


'able  to  deal  with  HMG  Operational  and 
Administrative  systems  of  all  sizes'; 

'able  to  encompass  all  technical  (eg  Hardware, 
Software,  Communications)  and  non-tochriicuJ 
(eg  Physical,  Personnel)  aspects  of  IT 
sccuri ty '  ; 

’compatible  with  existing  Government  IT 
Security  guidance*; 

'suitable  for  use  during  the  development  of 
a  system,  for  projects  as  well  as 
exist  i  rig  i  nsta  1  j  at  ions  '  ; 

'easy  to  use,  after  training,  by  staff  with 
IT  but  not  necessarily  IT  security  expor i once ' ; 

'able  to  be  used  such  that  reviews  can  be 
carried  out  quickly  enough  to  ensure  that 
results,  are  not  overtaken  by  changes  in  the 
system* , 

'.able  to  bo  used  with  an  automated  support  too] 

.  The  first  task  was  to  examine  existing 
methodologies  to  determine  if  any  met  the  HMG 
requirement:..  Several  methodologies  were  identified 
but  none  met  all  the  mandatory  requirements.  Whilst 
at  fir.st  glance  Annual  Loss  Expectancy  (ALE)  based 
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quantitative  approaches  seemed  attractive,  it. 
became  evident  that  the  inevitably  subjective  way 
in  which  figures  arc  attributed,  particularly  costs 
lor  data  assets,  could  produce  an  unsound  base  and 
inconsistencies  between  similar  reviews.  Also 
those  methodologies  typically  did  not  offer  much 
support  for  countermeasure  selection  with  a 
consequential  need  for  the  reviewer  to  have  IT 
security  knowledge,  couples  with  the  fact  that 
analysis  could  be  lengthy.  Existing  qualitative 
mothodo] ogi os  were  insufficiently  rigorous,  did 
not  cover  all  main  components  of  risk  management 
or  were  not.  sufficiently  far  enough  advanced  to  be 
of  use.  Therefore  it  was  decided  to  devise  a  new 
methodology  following  a  qualitative  approach,  hut 
wherever  possible  taking  quantitative  input,  and 
containing  no  'hidden*  logic. 

t>.  Accordingly,  a  "manual"  version  of  the 
methodology  has  been  produced  and  us  of  May  1987 
has  successfully  undergone  five  separate  trials 
encompassing  both  administrative  and  operational, 
and  existing  and  planned,  systems.  Comprehensive 
documentation  -  including  management  guidelines, 
the  logical  design  specification  for  an  automated 
support  tool,  and  <\n  outline  of  the  training 
course  required  for  its  use,  have  already  been 
produced.  Detailed  amendments  arc  being 
incorporated  in  the  documentation,  further  'beta' 
site  trials  to  ‘fine  tune'  the  methodology  are  in 
progress,  and  work  has  started  on  the  production 
of  an  automated  support  tool  and  a  comprohensi vc 
training  course.  CHAMM  is  now  the  'Preferred* 
met  hndnl  ogy  for  the  British  Government. 

Unclassified  but  Sensitive  *ai't*a'. 

OV EH VIEW  OF  THK  METHODOLOGY 

6.  The  methodology  comprises  a  staged,  or  modular, 
approach.  The  first  two  stages  address  analysis 

of  the  risk  and  the  third  and  final  one  addresses 
management  of  risk  through  the  implementation  of 
countermeasures.  Each  stage  is  supported  by 
questionnaires  and  guidelines  and  sets  out  to 
answer  one  m.  jor  question.  Simply  stated  these 
are :  - 

Stage  1:  is  there  a  security  need  above 

a  certain  baseline  level? 

Stage  ?:  where  and  what.  i.  the  extent  of 

the  security  need? 

Stage  3:  how  can  this  need  be  met? 

At  the  completion  of  each  stage  there  is  a 

formal  management  review. 

Stage  1 

7.  The  first-  part  of  Stage  1  is  the  important 
task  of  precisely  determining  the  nature  and 
boundaries  of  the  system  under  review,  and  its 
various,  component.:  .  This  is  accomplished  by  the 
acquisition  of  information  on  the  user  community 
and  the  manner  in  which  they  use,  or  will  use,  the 
system  -  together  with  an  outline  system 
configuration  diagram.  This  information  is 

otit  lined  from  interviews  with  senior  installation 
or  project  managers,  and  user’  managers  and  their 
staff,  and  is  essential  in  providing  the  reviewer 
with  trie  understanding  necessary  for  the  specific 


boundaries  of  the  review  to  be  agreed  and  later 
for  the  questionnaires  and  gui del ines to  be  put  into 
perspective.  Tt  also  provides  sufficient  detail, 
for  instance  on  the  number  of  'data  owners',  for 
the  review  to  be  scheduled.  Stage  1  then  continues 
with  its  major  function  -  the  determination  of 
qualitative  values  for  assets,  both  physical  and 
data.  The  CHAMM  documentation  provides  detailed 
advice  on  how  the  reviewer  should  schedule,  conduct 
and  record  interviews  with  data  owners  and 
personnel  responsible  for  physical  assets,  and  to 
review  results  with  system  or  project  management. 

A  carefully  structured  questionnaire  enables  the 
reviewer  to  establish  the  selection  of  qualitative 
values,  without  'user  bias',  for  the  four  possible 
impacts  -  disclosure  (of  data  assets),  modif ication 
(both  accidental  and  deliberate),  unavailability 
(of  data  assets)  and  destruction  (of  physical  or 
data  assets).  This  selection  is  aided  by  detailed 
'common  metric'  guidance  for  data  valuation 
covering  such  issues  as  political  embarrassment, 
commercial  conf idsntial ity ,  personal  privacy, 
financial  and  legal.  Physical  assets  such  a:; 
hardware  and  air  conditioning  plant  are  first 
valued  on  the  basis  of  replacement  or  reconstruction 
cost.'*.  -  which  are  then  converted  onto  the  same 
qualitative  scale  as  that  used  for  data  assets. 

An  advantage  of  the  methodology  is  that  time  and 
resource  wastage  can  be  avoided  where  all  values  are 
low.  In  these  circumstances  what  is  in  effect  a 
shortened  version  of  Stage  2  would  be  used  to  check 
whether  there  arc  any  threats,  vulnerabilities, 
or  combinations  thereof,  which  are  of  sufficient 
level  to  justify  greater  than  baseline  protection 
for  low  value  assets.  If  the  value  of  all  assets 
is  low  and  only  baseline  protection  is  justified, 
then  a  review  will  move  directly  to  Stage  3. 

Only  where  asset  values  arc  medium  or  high  is 
Stage  ?  recommended.  At  the  end  of  Stage  1,  as 
with  the  subsequent  two  stages,  there  is  a 
comprehensive  management  review. 

Stage  ? 

8.  The  extent  of  the  security  needed  by  a  system 
relates,  not  just  to  values  of  assets  but  also  to 
the  levels  and  nature  of  threats  to  which  the 
system  could  be  subjected  and  the  likely 
vulnerabilities  of  the  system  assets  to  those 
threats.  The  first  part  of  Stage  ?  is  concerned 
with  evaluating  the  dependency  of  a  system  or 
potential  system  on  certain  groups  of  assets,  not 
all  of  which  arc  vulnerable  tc,  the  same  potential 
threats.  Then  twenty-two  generic  threat  types, 
for  example  f  i  r-c ,  water  damage,  system  infiltration 
and  misuse  of  resources,  are  used  as  tno  basis  to 
assess  the  qualitative  threat  and  vulnerability 
levels  per  relevant  asset  group,  using  pairs  of 
structured  quest i onna j r»s  incorporating  the 
Knowledge  of  MMG  Security  expert:;.  As  far  a:; 
possible  questions,  arc  framed  so  as  to  prompt  a 
'yes'  or  'rio*  answer  to  avoio  'bias',  with  each 
answer  afforded  a  particular  score;  total  scores 
per  quest i onna i re  indicate  a  high,  medium,  or 
low  theca'  or  vulnerability.  lor  each  relevant 
asset  group,  the  combination  of  asset  value  and 
assessments  of  the  levels  of  vulnerabi 1 ities  and 
threat.:;  are  used  t.o  calculate  a  security 
requirement  (ie  risk)  number  on  a  scale  ol  one 
(baseline)  to  five,  for  each  ol'  the  four  possible 
impacts,  (ie  disclosure,  modification,  unavail¬ 
ability  anti  destruction).  At  the  end  of  Stage  ?, 
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management  has  a  clear  view  of  the  levels  of 
threats  to,  vulnerabilities  of,  and  tnun  risks 
to,  particular  asset  groups.  The  expression  of 
risks  in  a  numerical  form  enables  direct  natch  mg 
to  countermeasures  in  Stage  3*  The  completed 
analysis  of  risks,  ie  at  end  pf  Stage  ?,  is 
reviewed  in  detail  with  management  before  moving 
to  Stage  3- 

St-age  3 

9-  Stage  3  determines  how  the  identi  f  md  secur i  ty 
need  can  be  met,  ie  countermeasure  selection. 

Taking  the  determined  levels  of  risk,  ie  the 
security  requirement  numbers ,  for  each  asset 
grouping,  countermeasures  (covering  all  aspects 
of  security)  are  selected  from  a  large  'library' 
which  is  referenced  hy ,  ameng  other  things, 
security  aspect  (physical,  software,  etc)  and  is 
further  annotated  by  type,  eg  reduce  risk,  reduce 
impact,  detect.  If  the  review  is  of  a  current 
installation,  details  of  existing  countermeasures 
are  now  recorded.  (This  activity  is  deliberately 
kept  until  the  end  of  the  review  to  avoio 
prejudging  the  effectiveness  and/or  juat l f ication 
for  existing  countermeasures).  A  comparison  is 
conducted  to  ascertain  which  additional 
countermeasures  are  to  be  recommended ,  and  which 
existing  ones  are  not  justified.  As  the  list  of 
countermeasures  is  produced,  it  is  annotated  with 
likely  levels  of  cost  (from  information  held  in 
the  'library').  Then  costs  specific  to  the  actual 
or  likely  equipment  types  can  be  added,  and  a 
further  mans gem ent  review  is  held. 

10.  If  management  is  unhappy  about  some  aspect, 
eg  the  likely  overall  cost  is  outside  the  budget, 
"what  if"  questions  can  be  dealt  with  (for  example, 
wnat  would  be  the  effect  of  removing  one  very 
sensitive  file?).  In  other  words  a  parameter  can 
be  changed  and  the  methodology  "rc-run".  The 
final  step  is  to  determine  when  a  furtnor  review 
should  be  carried  out..  Much  of  the  information 
gathered  during  the  first  review  can  be  used  in, 
and  thus  greatly  speed  up,  subsequent  reviews. 

PRINCIPAL  CBAMM  CONCEPTS 
Stage  1 

11.  Stage  1  introduces  the  first  of  several 
concepts  used  in  CRAMM,  that  of  a  baseline  level 
of  countermeasures  which  would  always  be  applied 
to  any  system.  You  may  think  of  them  if  you  wish 
as  a  'code  of  good  practice*.  For  example,  for 
ether  than  truly  single  user  systems  the 
requirement  for  a  user  to  identify  himself  to  the 
system  during  log-on  might  be  defined  as  a 
baseline  countermeasure.  The  need  for  such  simple 
countermeasures  is  based  on  the  premise  that  an> 
system  must  be  of  some  value  to  the  organisation 
(or  why  have  it?;,  and  therefore  needs  a  certain 
level  of  control  - 

1?.  Further  protection  will  only  be  required 
if  the  importance  of  the  data  to  the  user  or  the 
value  of,  say,  the  hardware  merits  this  addition. 

The  principal  function  of  Stage  1  is  therefore  to 
establish  these  values.  As  mentioned  however, 

Stage  1  initially  establishes  the  scope  of  the 
review ,  and  details  the  system  configuration  and  the 
manner  in  which  the  system  is  used.  Only  when  a 
clear  picture  of  the  total  system  has  emerged  is 


the  first  real  risk  management,  task  tackled  -  that, 
of  establishing  the  boundaries  of  the  system  under 
review.  Experience  has  shown  this  to  be  an 
important  tasx  and  guidelines  are  given  to  aid  the 
process.  The  typical  modern  system  frequently 
interconnects  with  other  systems  which  themselves 
are  connected  again  to  further  systems.  It  is 
important  to  establish  therefore  up  to  which  point 
one  is  aiming  to  provide  a  secure  system. 

13*  Trie  importance  of  the  data  can  now  be  assessed 
by  detailed  questionnaires  dir- cted  at  the  owners 
and  users  of  data.  They  arc  asked  to  state  what 
the  effect,  on  the  organisation  would  be  if  the  data 
were  to  be  disclosed,  modified,  made  unavailable 
(loss  of  service),  or  destroyed.  Ihe  reviewer  is 
aided  in  recording  the  results  of  this  process  by 
a  series  of  guidelines  which  enable  him  to  place  a 
value  on  the  data  appropriate  to  the  manner  in 
which  it  is  used.  For  example,  if  the  data 
contains  details  of  legal  contracts,  he  will  ask 
what  the  effect  would  be  of  the  organisation  being 
iri  breach  of  contract.  Would  it  be  sued?  For 
how  much?  What  would  the  effect  of  the  publicity 
be?  The  guidelines  will  relate  this  to  a  scale 
of  1  to  10. 

1*J.  This  approach  t  •  establishing  the  importance 
of  the  data  to  the  organisation  has  been  found  to 
have  three  important  advantages : - 

(a)  users  can  much  more  readily  associate 
with  values  appropriate  to  the  system j 
they  are  not  forced  to  use  financial 
va 1 ues ; 

(b)  the  relative  values  that  h<ive  been 
established  could,  if  justified,  be 
easily  adjusted  to  an  organis.it ion  1  s 
own  perception,  without  in  any  way 
affecting  the  working  of  the 
methodology ; 

(c)  the  use  of  common  guidelines  helps 
to  prevent  user  bias. 

19.  Asset  valuation  is  completed  by  listing  the 
replacement  or  reconstruction  costs  for  hardware, 
software  and  environmental  facilities.  This 
enables  complete  understanding  of  the  importance 
of  the  system  to  be?  obtained  and  a  decision  can 
now  be  mace  as  to  whither  it  justifies  a  full 
scale  review,  cr  whether  an  abbreviated  approach 
ceuld  be  used.  This  facility  (which  is  incorporated 
within  the  meUiodol ogy )  avoids  creating  situations 
in  which  a  great  deal  of  time  and  money  is  spent 
investigating  the  risks  to  a  system  which  contains 
nothing  of  great  value. 

16.  Stage  1  is  completed  by  u  comprehensive 
review  with  management  to  agree  the  information 
collected.  At  this  stage  discussion  usually  centres 
on  the  extent  of  the  configuration  and  the  user's 
perception  of  the  importance  of  the  system.  These 
ore  unemotive  topics  and  consequently  agreement 

can  usually  be  easily  reached. 

Stage  ? 

17.  The  primary  function  of  Stage  ?  is  to 
evaluate  the  level  of  threats  to,  and  extent  of  the 
vulnerabilities  of,  the  system  assets.  However, 
another  important  concept  of  the  methodology  is  the 
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recognition  that,  different  Lnrc.it:;  may  apply  to 
different  parts  of  the  same  system.  Similarly, 
vul  nor.  ibi  1  ity  may  not  be  the  same  at  all  points . 

In  practienl  terms  though  it  would  he  prohibitively 
expensive  in  time  rind  effort  and  indeed 
unnecessary  to  explore  the  level  of  threat  against 
every  individual  asset.  Therefore,  using  CHAMH, 
assets  arc  grouped  in  a  manner  appropriate  to  the 
threat.  The  threat  of  lire,  for  example,  is 
likely  to  vary  by  physical  location  and  it  is 
therefore  appropriate  to  evaluate  this  throat 
against  all  the  assets  in  one  room  or  small 
building.  However,  by  comparison,  if  system 
infiltration  is  being  considered  then  the  total 
system  could  be  regarded  as  the  appropriate  group 
of  assets  since  it.  is  normally  not  practical  to 
separately  protect,  different,  parts  of  the  same 
system  against  this  particular  threat  type. 

18.  The  second  part  of  Stage  P  establishes  the 
security  requirement  (measure  of  risk)  of  each 
group  of  assets  by  relating  together  the  value  of 
the  assets  (including  data),  the  level  of  threats 
to  which  it  is  likely  to  be  exposed  and  the 
degree  of  vulnerabi 1 i ty .  The  first  of  these  has 
been  expressed  on  a  scale  of  1  to  10  and  the 
other  two  on  a  high,  medium  or  low  basis.  A 
matrix  is  used  to  link  the  three  factors  together 
and  express  the  result  on  a  scale  of  1  to  b. 

19.  The  significance  of  dividing  the  system  into 
assets  or  groups  of  assets  becomes  more  apparent 
when  it  is  appreciated  that  the  security 
requirement,  figure  will  be  used  to  determine  the 
level  of  cuuntet measures .  Hence  an  asset  'with  n 
high  value  associated  with  it.  may  have  a  higher 
security  requirement  than  an  asset  of  lower  value 
but  the  same  threat  arid  vulnerability  rating.  The 
correct  level  of  protection  is  therefore 

est-abl  ished  for  all  parts  of  the  system.  Blanket 
coverage,  which  frequently  results  in  under  or 
over  protection  for  particular  assets,  is  avoided. 

Stage  3 

PC.  Stage  3  is  concerned  with  establishing  the 
countermeasures  necessary  to  meet  the  security 
requ i rcinont.  calculated  from  the  analytical  work 
of  the  first  two  stages.  It-  therefore  moves 
positively  from  risk  analysis  to  risk  management. 
Thin  is  an  area  which  appears  to  have  received 
relatively  little  attention  in  other 
methodologies,  yet  the  task  of  selecting 
countermeasures  is  a  formidable  one.  for  example, 
a  major  installation  or  network  may  require  several 
hundred  countermeasures  to  hr  implemented.  These 
could  range  from  procedures  for  assigning  passwords, 
to  check  controls  over  input  data,  to  encryption, 
tu  firn  extinguishers  in  the  general  office.  The 
range  is  enormous,  making  selection  extremely 
difficult . 

Pi.  Stage  3  tackles  this  problem  by  grouping 
countermeasures  together  (countermeasure  groups) 
and  relating  these  to  threats.  For  example, 
procedural  controls  over  system  programmers  will 
relate  to  the  threat  of  systems  infiltration 
(unauthorised  access).  The  first,  step,  therefore, 
is  to  select  the  appropriate  countermeasure  groups 
for  each  threat  .  At  this  stage  a  considerable 
degree  of  overlap  is  likely  to  be  observed. 


Physical  access  countermeasures,  for  example, 
address  several  threats,  (wilful  damage,  theft , 
etc!.  This  overlap  indicates  that,  these  types  of 
countcrmcasi re  arc  likely  to  be  essential. 

P-2 .  Having  selected  the  countermeasure  groups,, 
the  rev i ever  then  has  access  to  an  extensive  list 
of  several  hundred  count ormonsures  (arranged  undue 
these  group.;)  each  of'  whicr  has  been  assigned  a 
rating  of  between  1  (very  low,  or  baseline)  and 
b  (very  high).  These  ratings  correspond  to  the 
score  calculated  when  deriving  the  security 
requirement. ,  and  thus  the  reviewer  ean  easily 
select  the  appropriate  countermeasures. 

P3-  For  an  existing  installation,  the  same  list 
can  now  be  useci  to  examine  the  previously 
implemented  countermeasures.  These  are  then 
compared  against  those  identified  as  necessary  by 
CRAMM  and  recommendations  made  where  there  arc 
discrepancies.  While  normally  the  recommendations 
will  address  the  requirement  for  additional 
countermeasures,  this  is  by  no  means  always  the 
case.  In  some  instances  in  our  'beta'  trials, 
recommendations  have  been  made  to  consider 
removing  countermeasures  which  did  not  seem  to  be 
justified  _ 

CONCLUSION 

2i  1.  Thus  to  conclude,  the  main  CRAMM  concepts 

arc :  » 

baseline  level  of  countermeasures; 

-  'common  metric1  guidance  for  qualitative 
valuation  of  data  assets  for  the  four 
major  impacts; 

-  no  presumptions  made  as  to  the  need  for 
previously  implemented  countermeasures ; 

-  qualitative  assessment  of  threat  types 
against  specific  groups  of  assets; 

qualitative  assessment  of  the  vulnerabilities 
of  these  specific  groups  of  assets; 

combination  of  qualitative  values  for 
assets  and  threat  and  vulnerability  ratings 
to  form  numeric  indications  of  risks; 

-  matching  numeric  indications  of  risks  t.o 
specific  countermeasures ; 

-  Tor  an  existing  installation  identifying 
not.  only  justified  but  also  unjustified 
countermeasures . 

We  feel  that  those  wore  needed  to  meet  the  originally 
specified  criteria  for  a  methodology  for  the  UK 
Government . 

Plj.  Indeed,  the  'manual'  methodology  has  been 
produced  and  tested  and  it  is  evident  that,  with  the 
use  of  the  automated  suppor  tool  to  considerably 
reduce  review  time,  it  fulfils  the  specified 
requirements.  Particularly  popular  with  trial  site 
staff  has  been  the  'common  metric*  guidance  for 
establishing  qualitative  data  values,  and  the 
production  of  lists  of  specific  countermeasures. 
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?b  .  Tt  i a  now  clear  that,  information  col  looted 
during  a  review  could  be  used  to  identify 
particular  evaluation  needs  ana  to  construct 
security  policy  and  requirement  documents.  Indeed 
the  methodology  wi’l  he  invaluable  to  management 
in  presenting  easily  understandable  results  in 
the  form  of  countermeasure  lists  justified  in 
accordance  with  the  real  security  need  (and  for 
existing  installations  identifying  countermeasures 
which  may  not-  be  justified  and  could  be  removed  - 
probably  with  cost  saving  and  casing  of 
operational  constraint.).  Management  will  thus 
be  able  to  consider  submissions  for  money  spend 
on  security  supported  by  a  logical,  properly- 
constructed  and  justified  case. 


ROBIN  MOSES 
COTA 

PO  May  1987 


It  should  be  noted  that  the  CCTA  methodology, 
CRAMM,  is  Crown  Copyright. 
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There  is  a  significant  interest  and  need 
in  the  computer  security  community  to  have 
effective  tools,  techniques ,  and  guidance  for 
completing  the  risk  management  process.  The 
National  Computer  Security  Center  and  the 
National  Bureau  of  Standards  have  jointly 
sponsored  forums  for  exchanging  ideas  and 
presenting  approaches  to  risk  analysis.  These 
two  organizations  have  identified  the  major 
issues  in  risk  management  and  have  embarked  on 
a  plan  that  describes  the  steps  necessary  to 
resolve  the  problems,  lays  the  foundation  for 
developing  a  comprehensive  model  for  risk 
management,  and  provides  guidelines  for 
conducting  the  process  and  selecting  effective 
safeguards  for  computer  systems.  The 
cornerstone  of  the  plan  resides  with  the 
construction  of  the  conceptual  model  of  the 
risk  management  process.  This  model  will 
describe  the  interrelationships  of  the 
components  of  risk,  management  (e.g.,  throats, 
threat  frequencies,  vulnerabilities, 
safeguards,  risk,  outcomes)  in  a  formal  way  so 
that  we  all  have  a  common  understanding  of  the 
risk  management  process.  This  conceptualiza¬ 
tion  will  help  explain  where  alternative 
methods  or  approaches  fit  into  the  overall 
pr  oceso . 

The  panel  activity  will  begin  with  a 
presentation  of  the  elements  of  the  road  map 
for  the  future  of  risk  management.  This 
discussion  will  include  the  conceptual 
framework,  the  creation  of  a  risk  management 
laboratory  and  testbed,  case  studies,  data 
acquisition,  model  development,  and  related 
topics.  Panelists  will  have  an  opportunity  to 
critique  the  plan  and  present  alternative 
recommendations.  The  panel  will  conclude  with 
a  15-  to  20-minute  question  and  answer- 
session.  Fanel  membership  will  consist  of 
Stuart  Katzke  of  NBS ,  Sylvan  Pinsky  of  NCSC, 


ABSTRACT 


The  federal  government  and  private 
industry  have  a  long-standing  interest  in 
conducting  computer  security  rick  analyses. 
Analysis  is  part  of  the  larger,  more 
comprehensive  "risk  management"  process  which 
describes  the  types  of  approaches  and  methods 
that  address  all  activities  leading  to  cost- 
effective  safeguards  for  automated  information 
systems.  Numerous  computerized  tools  have 
emerged  over  the  last  3  years  to  assist 
analysts  in  completing  the  risk  management 
process.  Each  of  these  models  deals  with  only 
one  aspect  of  the  total  process,  such  as 
vulnerability  assessment,  threat  assessment, 
or  annual  loss  expectancy  calculation. 
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Abstract 

This  paper  reports  briefly  upon  the  progress  of  the 
m-EVES  research  and  development  project,  m  EVES 
is  a  prototype  verification  system  being  developed, 
under  contract,  by  I.P.  Sharp  Associates  Limited. 


1  Introduction 

The  major  goal  of  the  m-EVES  research  and  development  project, 
is  to  design  and  to  implement  a  program  verification  system  1 
which  satisfies  the  following  requirements: 

•  The  system  is  to  be  based  upon  sound  mathematics. 

•  The  system  is  to  include  state-of-the-art  techniques  in  the¬ 
orem  proving,  workstations,  compilers,  and  existing  math 
ematics. 

•  The  system  /nay  be  used  to  develop  programs  required  to 
satisfy  NCSC  Al-t-  and  UK/Canadian  equivalents. 

Oui  project  is  divided  into  two  distinct  phases.  In  the  first 
phase,  we  arc  to  develop  the  m  -EVES  environment;  in  the  sec¬ 
ond  phase,  we  are  to  develop  EVES. 

m  -EVES  is  to  be  a  research  and  pedagogical  environment, 
that  emphasizes  program  verification  concepts.  The  system  will 
handle  a  new  programming  and  specification  language  (called 
m  -Verdi),  a  new  prototype  theorem  prover  (called  m  NEVER), 
sundry  workstation  ideas,  and  will  have  a  production  quality 
compiler  for  in  Verdi. 

The  essential  roles  of  the  in  EVES  environment  are  as  follows: 

•  To  be  used  for  instmrting  our  clients  about  program  veri¬ 
fication  techniques; 

•  To  allow  us  to  test  various  unproven  ideas  before  commit  - 
ting  to  a  design  for  the  EVES  environment;  and 

•  To  obtain  feedback  from  the  various  decisions  we  have  al 
ready  made.  This  includes  decisions  respecting  mathemat¬ 
ics,  language  and  prover  capabilities. 

EVES  is  to  be  the  production  quality  verification  environ 
Iliellt.  EVES  will  handle  a  dialect  of  m  Verdi  (called  Verdi), 
which  will  have  significantly  stronger  specification  and  program 
tiling  structures;  and  will  include  a  state-of  the  art.  theorem 
prover  (called  NEVER),  a  collection  of  specification  and  pro 
gram  analysis  tools,  and,  of  course,  various  compilers  for  Verdi. 

■1(1  tins  paper,  I  do  not  want  to  spend  time  discussing  the  rather  lengthy 
history  of  the  BVKS  project  Another  paper  jC'rn  3fla]  disc  usses  the  history 
of  the  project  and  the  evolution  of  out  thoughts 


One  immutable  requirement,  of  our  project  is  that  both  m  - 
EVES  and  EVES  must,  have  a  sound  mathematical  basis.  We 
maintain  that  every  verification  system  should  be  able  to  ex¬ 
hibit  such  a  basis;  otherwise,  one  must  question  the  mathemat¬ 
ical  proofs  arising  from  the  system.  For  example,  many  of  the 
current  (North  American)  systems  do  not  check  whether  de¬ 
clared  functions  arc  well-defined.  An  elementary  example  of  an 
ill-defined  function  is  the  following  Boolean  function: 

Russell(x)  is  defined  as  not (Russell(x) ) 

Such  an  ill-defined  recursion  allows  one  to  prove  the  theo¬ 
rem  “FALSE”  which  then  throws  into  doubt  any  pretensions  ot 
'•erified  software.  While  such  pathological  examples  are  easy  to 
recognize,  we.  have  to  be  concerned  about  the  subtle  occurrences 
of  such  events.  Another  paper  [Cra  80b]  discusses  in  more  detail 
some  of  the  generic  strengths  and  weakiusses  of  current  verifi 
cation  systems. 

Of  course,  even  with  such  a  mathematical  basis,  there  may 
be  luisounduess.  As  an  example  of  a  different,  kind  of  unsound- 
mss,  consider  the  incorrect,  (or  incomplete)  implementation  of 
the  verification  system  itself.  Note,  however,  that  the  presence 
of  the  mathematical  basis  opens  the  door  to  the  possible  verifi¬ 
cation  of  components  of  the  verification  system  itself;  its  absence 
completely  negates  such  a  possibility. 

Currently,  our  project  is  focussing  upon  the  m  EVES  envi 
ronment.  It  is  expected  that  the  system  will  be  completed  by 
November  1987. 

The  m  EVES  development  has  generally  followed  two  streams: 

•>  The  design  of  in  Verdi  and  its  underlying  mathematics. 

•  The  development  of  the  m  NEVER  theorem  prover. 

In  the  remainder  of  this  paper,  I  will  discuss  briefly  each  of 
these  streams. 


2  m- Verdi  Development 

The  major  requirement  of  the  ill  Verdi  language  design  is  that 
m  Verdi  support  the  development  of  verifiable  software.  By 
verifiable  it  is  meant  that,  rigorous,  mathematically  sound  proofs 
(that  a  program  is  in  consonance  with  its  specifications)  are 
possible.  To  attain  the  goal  of  verifiability,  the  requirements 
were  refined  to  include  the  following; 

•  A  formal  semantic  description  of  in  Verdi  must  be  pre¬ 
sented,  and 

•  A  sound  logic,  for  reasoning  about  m  Verdi  programs,  must 
be  developed. 
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Tin1  ni  Verdi  language  was  tie-signed  basically  as  a  “proof  of 
conrrpt”  language.  VV<*  \vaiit;tl  to  show  I  hat  rigmuiis  matin* 
unities  t'ould  1m*  developed  to  suppoit  I  In*  v«rifi<*at-ion  proerss 
and  tlif  language  used  as  a  part  of  that  process.  As  not rd 
nbtivr,  wht'ii  vvr  mow  onto  the  stvoml  si  ago  of  tin-  piojrrl,  tin* 
di*vt*lopim*lit  of  EVES,  \v«*  will  t'nbniirt*  flit'  language  with  mor** 
powerful  ^predication  and  pioginuiniiiig  facilities  resulting;  in 
Verdi. 

The  design  of  ui  Venli  lias  lrd  to  a  language  which  is  quih* 
different-  from  its  Pascal  hast'd  forbears,  even  though  many  ol  the 
saint*  concepts  are  found,  it  was  a  matter  of  d  it  ft  rent  packaging 
and  appropriate  simplification. 

1  have  iueluth'tl,  at.  the  end  of  th«  paper,  an  example  in  Verdi 
program.  This  program  has  het*n  venlietl  using  the  111  1CVKS  en 
viroiuneiit.  as  it  existed  in  early  1987*.  Since  that  enviromneiit 
was  incomplete  (for  example,  the  well  fonnaliu'ss  of  procedures 
was  not  yet.  implemented),  it  is  possible  that  an  error  may  have 
slipped  through.  1  remind  the  reader  about  my  previous  com 
incuts  relating  t  o  unsound  ness.  (However,  this  example  has  also 
hern  processed  by  an  m  Vertli  compiler  and  no  well  formedness 
errors  wire  uncovered.) 

An  m  Verdi  compiler  has  been  implemented  on  a  VAX/750 
running  VMS*1.  To  enhance  tlu*  r<  target  ability  of  tin*  compiler, 
the  Code  Generator  Synthesis  System  (CGSS)  of  Karlsruhe*  Uni 
versity  is  being  used.  As  a  result,  we  an*  now  one  of  the  (few) 
sites  t  hat,  is  in  the  position  of  being  able  to  execute  verified  code. 
As  a  case  in  point,  a  simplified  version  of  the  Flow  Modulator 
was  verified,  compiled  and  then  executed  on  the  VAX. 

In  the  following  subsection,  1  have*  included  an  edited  section 
of  t  he  in  Verdi  reference  manual  [Cm  37]  which  presents  a.  brief 

overview  of  the  language. 

2.1  ill  Verdi  Overview 

A  (Ivclnnitiou  is  used  to  introduce  a  set  of  new  symbols  to  a  vo 
calmlary  and  to  prescribe*  properties  to  these*  symbols,  m  Verdi 
requires  declaration  befme  use  and  disallows  the  redeclaration 
of  symbols.  There  are  five  different,  kinds  of  symlKils:  Constant 
symbols.  Variable  symbols,  Typo  symbols.  Function  syinlnds, 
and  Procedure  symbols. 

A  Type  symbol  denotes  a  set  of  values.  A  Constant  symbol 
denotes  a  fixed  value  of  a  fixed  type.  A  Variable  symbol  may  be 
used  in  valuations.  A  Function  symbol  denotes  a  function.  A 
function  is  a  mapping  from  an  //  tuple  of  values  to  values  of  a 
fixed  type*.  A  Procedure  symbol  denotes  a  procedure 

An  axiom  restricts  tin*  possible  interpretations  for  the  sym 
hols  in  a  vocabulary. 

Tin*  Until,  Iul,  Char  and  Ordinal  types  belong  to  the  ini 
rial  vocabulary  (i.e.,  the  predefined  in  Verdi  symbols).  With 
each  type,  a  set  of  literals,  and  constant,  variable  and  function 
symbols  are  defined.  The  Bool  type  denotes  the  logical  truth 
values.  The  hd  tyjK*  denotes  the  j«*t  of  unbounded  matliomat 
ical  integers.  The  Chur  type  denotes  a  finite  set  of  graphic 
symbols.  The  Onlnml  type  denotes  an  initial  segment  of  the 
mat lieuiat ical  ordinals  (up  to  u/u’).  Other  types  are  introduced 
through  an  Enumeration  type  declaration,  a  Restriction 
type  declaration  (which  defines  a  set.  of  values  using  an  ex 
plicit  Bool  predicate1),  an  Array  type  declaration  or  a  Record 
type  declaration. 

An  Expression  is  an  in  Verdi  sentence  which  may  be  eval 
unted  (Using  a  vocabulary  and  valuation*)  to  pmdiue  a  value 

2‘1’ln*  system  has  lu'c-n  significantly  iiioihfnd,  sine*'  1  j>r»v<-<|  tin*  example, 
as  a  result  of  <h*cisi(»iis  made  during  the  spring  ot  1  UK r*  We  have  modified 
the  m  EVES  in  ter  far  i-  «:n  that  interaction  now  occurs  through  a  roiumaini 
language.  This  point  is  discussed  further  in  §4- 

3 VAX  and  VMS  are  trademarks  of  Digital  Equipment  l 'orporatioli. 

4 A  v; .hiation  is  a  pairing  of  variable  symbols  with  values. 


of  u  fixed  type.  The  Expressions  me  equality,  inequality,  eval 
nation  of  a  constant,  evaluation  of  a  variable,  evaluation  of  a 
parenthesized  expression,  evaluation  ot  a  function  application, 
evaluation  of  a  constructor,  and  evaluation  of  conditional  and 
quant iiication  expressions. 

A  Command  is  an  m  Verdi  sentence  which  denotes  om*  ot 
more  execution  stops  and  determines,  in  part,  the  oi deling  of 
the  execution  step.-*.  It  is  through  the  execution  of  ronm  lids 
that  t.lii*  values  associated  with  a  program’s  obsci vahles’  and 
valuations  are  modified.  The  in  Verdi  commands  are  exit 
(from  a  loop),  return  (from  a  procedure),  abort  ( the  program), 
Assignment  command, Annotation,  Procedure  call  command. 
Conditional  command,  Loop  command,  ami  flu*  Block  command. 

Certain  m  Verdi  roust i  nets  are  used  solely  for  specifying  funr 
tional  lehit ionslnps  These  are  the  Initial  clause,  Pre  con¬ 
dition,  Post  condition,  Measure  condi tion  (used  in  proofs 
of  termination  ;  ud  well  drhnrd.icss  of  recursive  functions),  In¬ 
variant  (of  a  loop)  and  Annotation  (m  Verdi's  equivalent.  of 
the  assert  coinmaud).  |Saa  87]  discusses  in  detail  tin*  proof  the 
oretic  issues  arising  from  tlu  language. 

A  Package  collects  tog«  thor  a  sequence  of  declarations  and 
restricts  the  availability  of  certain  symbols  in  tin*  sequence.  A 
Package  may  he  used  to  support  info!  mat-ion  hiding  and  ah 
st  ruct  ion. 

An  Environment  is  used  to  introduce  symbols  which  will  form 
a  link  between  the  i:i  Verdi  program  and  t  he  program's  observ 
aides.  Symbols  may  also  he  introduced  to  support  the  expression 
of  specifications.  The  Environment  acts  a>:  part,  of  tin  axiomatic 
basis  to  an  m  Verdi  program.  The  Environment  will  include  the 
specification  of  routines  which  cannot  he  implemented  in  m 
Verdi  but.  are  crucial  to  its  execution  and  its  ability  to  modify 
the  obsci  vahles. 

2.2  Mathematics  and  Extensions 

The  seniiiiitic  basis;  (if  the  language  is  described  using  a  form  of 
Denot atioiiid  Seinantics.  There  are  no  real  surprises  in  thi;-  part 
of  Ihe  work. 

Much  more  interesting  problems  arose  with  the  development 
of  a  logical  system  for  reasoning  alxnit  m  Verdi  programs.  In 
fact.,  this  area  required  the  development  a  new  logical  system 
(by  my  colleague  Mark  SaaUink)  [San  87],  It  is  worthwhile  not 
ing  that  Predicate  Calenlns  systems  are  inadequate  for  reasoning 
about  and  specify  ing  programs.  Fm  example,  the  Predicate  Cal 
enlns  does  not  handle  recursive  functions  nor  the  introduction  of 
new  symbols  to  the  vocabulary  of  the  logic.  The  logic  is  based 
upon  Geutzcu  style  deduction. 

Each  declaration  in  an  in  Verdi  program  requires  an  aerep 
tanee  proof.  For  example,  recursive  functions  must  be  well  dc 
fined  and  verification  conditions  (the  acceptance  criteria)  foi 
procedures,  which  are  generated  using  a  Verification  Condition 
Generator  (VCG),  mast,  alsi  be  proven.  The  logic  has  been 
shown  to  be  sound  relative  to  the  I)euot.ationnl  Semantic  model 
and  readers  should  note  that,  since  the  VCG  is  a  part-  of  the 
logic,  wr  have  proved  that  the  VCG  perforins  the  correct  anal 
ysis  of  procedures.  Tin  mathematics  is  completely  described  in 
Mark  Saalt ink's  paper  [Saa  87). 

Some  of  the  intended  additions  to  m  Verdi  include  polymor 
phisui  and  higher  order  functions.  Other  additions  are  lather 
basic  (e.g.,  for  loops  and  ease  commands);  such  facilities  were 
not  included  in  in  Verdi  since  they  were  only  “quantitatively" 
interesting,  not  “qualitatively'’  interesting.  All  of  these  addi 
tions  will  materially  improve  the  cxprcssihility  of  the  specifics 
tion  and  pingraiuming  facilities  of  the  language  and  will  more 
usefully  support,  the  development  of  reusable  mathematical  the 
dries. 

I'I’lir  visible  rflrrt  uf  a  program's exernt loll  is  rornpfetcly  ascertained  trolll 
tlir  set  of  observables. 
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3  m  NEVER 


'l'lir  oml  major  research  stream  <>f  the  piujeel  is  (lie  (level 
ojiiiieut  of  ti  new  tlicdiein  plover.  This  proves  incorjxirat rs  a 
number  «»f  t(vlnii<|ucs  that  are  urolrr  investijsiilon  by  the  t.heo 
trill  proving  eoiiiintiuity. 

Tile  pl’oiolype  plover,  called  ni  NI‘A  KR  (Not.  the  J'.VKs  He 
writer),  consists  of  six  conipom-iits:  a  simplilier  (a  Imitolngv 
checker  augmented  with  Nelson  Onpen  confluence  closnte  and 
linear  programming  teclini(pte.s),  a  rewriti  r  (that  handles  condi 
t  ional  rewriting  wit  h  backehaiiiing,  forward  rules,  and  allows  for 
rules  which  .permute  parameters);  an  invoker  (that  heuristically 
expands  function  definitions);  a  reducer  (that  reduces  a  formula 
by  an  innermost-leftmost  application  of  simplification,  rewriting 
and  invoking  to  each  of  the  subexpressions  of  a  formula;  the 
reducer  uses  a  cache  to  maintain  valid  reductions  and  thereby 
significantly  improve  its  performance);  user  commands  (exam 
pics  include  split ,  invoke,  prove,  undo,  and  try),  and  the 
required  support  for  I/O  and  database  management.  An  in 
duction  imvlianism,  which  is  modelled  on  the  approach  used  by 
Royer  f^oore,  is  also  included. 

The  theorem  prover  supports  the  interactive  development  of 
proofs,  but  also  has  powerful  automatic  tools.  For  example, 
there  is  a  command  which  instructs  the  prover  to  luing  all  of  its 
heuristics  to  hear  (including  conditional  rewriting,  and  proof  by 
induction)  on  a  proposition.  Other  commands  are  much  more 
selective  in  choosing  portions  of  the  plover's  capabilities  to  he 
applied  to  a  proposition.  Users  of  the  prove!  may  instinct  the 
prover  whether  facts  tire  to  he  used  as  lemmata  or  as  forward 
or  backward  chaining  rewrite  rules.  The  capability  for  di  luting 
icwiiie  rules  can  gmatiy  deeieti.se  the  amount  of  manual  inter 
action  re<ptircd.  The  decision  to  support  powerful  automatic 
features  and,  yet,  to  allow  for  selective  user  control  is  tt  funda 
mental  design  decision.  As  the  developers  of  n  NKVKIt  have 
stated  elsewhere  |1’K  87]: 

“  Although  NEVER  provides  powerful  deductive  tech 
niiptes  for  the  autoiuatir  proof  of  theorems,  it  also 
inclmlcs  simple  user  steps  which  permit  its  use  as  a 
system  more  akin  to  a  proof  checker  than  a  theorem 
prover.  ...  It  represents  a  tacit  admission  t lint  we  do 
not.  intend  to  develop  a  deductive  system  which  is  fully 
automatic;  rather,  for  sonic  proofs,  it  may  bo  essential 
for  the  user  to  resort  to  hand  steps,  since  the  automatic 
capabilities  may  he  inadequate. 

The  result,  of  combining  the  manual  and  automatic 
functions  within  a  single  system  creates  the  possibility 
of  ji  synergy  between  abilities  of  the  system  (fust  ami 
accurate)  and  the  user  (»  a*  necessary  insight)." 

One  <>f  the  major  f>< istls  of  tliis  effort  is  to  develop  a  prover 
which  allows  for  journal  level  inference  steps,  thereby  addressinp 
our  of  tin*  problems  with  previous  verification  systems.  A  liiorr 
complete  description  of  tlw  provei  may  hr  found  in  |1M\  87]. 

As  ;iu  indication  of  tin*  theorem  plover's  power,  it  has  hreu 
used  to  successfully  pruve  many  of  the  problems  fioin  the  Kem 
merer  Assessment  Study  of  vrriiiratiou  systems  [Kent  80],  l\em 
iiirrer’s  1/ihr.uy  Specification  |Kem  80j,  David  Cries’  Tsquare 
[Cii  82]  and  the  <‘oiisistri»cy  of  theories  desciihinp  a  sequence 
theory  aud  a  theory  of  sets. 

4  m  EVES  Interface 

The  V(*rihr;it  ion  system  runs  upon  Symbolics  hardware  and,  con 
frequently,  makes  use  of  the  windowing  soft-waie  and  piaphies 
packages-  It  is  ex]><*cted  that,  these  facilities  willpjeatly  increase 
the  utility  of  the  system.  (  Hither  .1  St i other  Moore  oi  lh»h  lJoyei 


once  told  us  tint  the  jmwer  of  (In'  Ho\ej  Mooje  piovci  cmiltl 
be  increased  by  an  order  of  magnitude  solely  by  inci easing,  the 
hand  wit  It  h  of  infm  mat  ion  hctwccn  the  j»j  over  aiul  tin'  individual 
usinp  t)ie  prover.) 

The  internet  ion  with  Jii  lOVKS  occurs  usinp  a  “pi over  coin 
niand  lanpuape"  (pci)  and  may  occui  usinp  either  an  KM  ACS 
biille  r  oi  a  Lisp  Listener.  'There  are  six  classes  of  eommands: 

•  Goal  Commands  'The  t  hive  comnniuls  retry,  try  and  try 
next-  untried  are  used  to  select  a  proposition  for  jooof. 

•  Hr* »of  Steps  These  commands  aj  e  t  he  basic  t  lieoi eni  j>i over 
eouimands  for  modifying,  a  proposition.  Kxamplcs  have 
been  enumerated  previously. 

•  Package  Commends  'The  majoi  unit  of  abstraction  and 
en«  psulation  in  m  Verdi  is  the  package  constiuct  'There 
are  -ix  eonmi.mds  for  id<  ulifyinp  t  he  b**phininp  and  end  of 
a  package,  the  hepimiinp  and  end  of  an  environment,  and 
tin*  bepinninp  and  end  of  a  package  model. 

•  Database  Commands  These  commands  elieit  information 
about  proof  status,  information  pertaining  to  vaiious  pi  oof 
events,  the  undoing,  of  j>mver  events,  and  the  free/.inp  and 
thawing,  of  the  database. 

•  Declarations  These  commands  are  essentially  m  Verdi 
declarations.  However,  the  pci  has  penerali/ed  the  in  Veidi 
axiom  declaration  to  include  further  information  peilinent 
to  the  proof  process  (e.p.,  tipper  expressions  for  forward 
rules)  and  packapes  are  handled  differently  (as  noted  above). 

•  Miseellany  'These  commands  are  used  to  reset  tin*  prover 
to  its  initial  stale,  to  hepin  ami  end  scripting,  to  quit  the 
plover,  and  to  read  m  a  tile  of  juover  commands. 

'Tin*  pci  inteiface  is  now  in  place  (as  of  May  1‘  C)  but  some 
of  the  commands  are  not  supported.  The  eonnnands  of  panic 
ular  not<‘  are  those  dealing  with  the  environment  and  packages. 
While  the  environment  commands  will  be  easy  to  handle,  some 
rather  significant  modifications  to  the  prover  must  be  made  to 
properly  handle  paekap.es. 

The  environment  will  fully  support  tin*  plover's  capabilities 
for  interactive  provinp.  As  a  result,  when  one  is  tiyinp  to  piove 
a  proposition  and  notes  that  some  subsidiary  facts  are  necessary, 
it  is  possible  to  introduce  the  new  facts  and  oil  her  piove  them 
immediately,  or  temporarily  assume*  them.  (This  facility  will  no 
lonper  be*  available  after  chanpe*s  an*  made  dm  inp  t  lie*  summer  of 
1087.  In  particular,  to  simplify  the*  checkinp  for  non  circulmity 
of  proofs,  each  declaration  must  be*  pi  oven  as  it  is  added  te)  tin* 
syste'iu.  T  he*  only  instance  where  prorfs  may  b<*  ele*te*rre*el  will 
occur  when  puckape  headers  may  be*  added  and  the  conespond 
inp  packape  body  deferred.  However,  wh<*n  it  is  time*  to  ad«l  the 
packape  body,  the  prover  state*  will  have*  to  be  returned  to  the* 
state  oeeurrinp  afte  r  tlu*  piexeelure  header  was  added:  subse 
quently,  the*  packape  body  may  be*  added  and  the*  rations  pi  oof 
obhpations  satisfied.  The*  appioaeh  of  iorrinp  prooi  when  a  dec¬ 
laration  is  beiup  aelejed  is  siliulai  to  the*  approach  use*d  by  Boyer 
and  Moore.) 

Kor  now,  it  the*  piopiam  is  to  be  eompiled,  it  has  to  be*  trails 
mitteel  to  a  \  AX  (see  §2).  It  is  still  uurleai  whether  an  in  Verdi 
compiler  will  ultimately  |e*side  on  the*  Symbolics  inacliHie*  and 
we  have*  yet  to  considei  the  issues  of  increrient al  eompila*  ion. 
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5  Conclusion 

Tin  jiroji  rt.  will  result-  m  four  major  advances: 

•  'l'ln* design  ami  implement  at  ion  of a  piogi  ninniing  and  spec¬ 
ification  language  which  lias  a  complete,  formal  mat  licmat 
it*:i  1  basis  amt  suppoi  I  ing  logic. 

•  Thf  design  of  a  sound  and  complete  logical  system  which  is 
sutlificiil  ly  powerful  to  handle  const  nuts  used  in  tin*  veri 
lien  lion  process. 

•  A  new  theorem  prove*  which  incorporates  many  of  t  in*  state 
of  tin*  art  concepts  currently  under  investigation  in  the  the 
oiciu  proving  community. 

•  The  usr  of  workstation  technology  to  enhance  the  interne 
t.ioii  In* tween  programmer  mid  verification  system. 

We  l'.’ivi*  t  ried  to  learn  from  the  experiences  of  the  exist  ing 
veriticat ion  system  eiforts  (e.g.,  |Kein  80]  [Cra  80]  [Cra  8G1>]). 
Our  development  of  a  solid  mathematical  foundation  allows  us  to 
present  sol  in*  strong  statements  about  cur  efforts  and  opens  the 
door  to  vilifying  components  of  the  veritieation  system,  lou  t  her, 
wc  attempt  to  ilecrease  tin*  cost  of  the  verilication  eilott,  l>y 
increasing  the  power  of  the  thenieiu  p  rover,  environment,  and, 
ultimately,  when  m  Venli  is  strengthened,  tin*  specification  and 
programming,  language. 

0  Acknowledgements 

The  following  individuals  have  been  involved  in  either  t  hi'  tech 
meal  or  support  stall  aspects  of  the  project:  David  Boiiyuu, 
limit  la  Brown,  Seiitot  hrnnioduuorljn,  Irwin  Moiseis.  Ai:  iors 
Neilsoti,  Bill  Base,  Mark  Saaltink,  Karen  Sutumciskill  and  my 
self,  Dan  Craigon. 

The  language  was  developed  hy  Craigon  and  Saalt  ink.  The 
mat  hemat  ics  is  due  primarily  to  Saaltink.  in  Nl'VKW  is  being 
ilevclopcd  By  Paso  and  Kromndiiuneljo.  Moist'!:;  and  Neilson  an* 
iiuplciiK  utiii£  tin*  m  Verdi  compiler. 

7  Micro  Flow  Modulator 

The  rather  simple  example  described  here  is  tleiived  fn»m  an 
Ailinn  description  of  a  ilow  modulator  which  1  specified  during 
tin*  Kcimuerer  Assessnu'nt  Study  [Keni  8(i][('ra  S5j. 

Suppose  we  have  two  computci  systems,  l’uhlic  and  Piivate. 
It  is  intended  that  messages  will  he  allowed  to  flow  from  the 
1'rivnt  e  system  to  the  Public  system  if  the  messages  satisfy  a 
]>art  iculiil  Boolean  pretlieate  detiued  over  messages.  (Such  a 
predicate  may,  for  example,  cheek  that  no  sensitive  information 
is  being  pnldienlly  dissemnnt ed. ) 


1’iililii1 

, 

I'l  iv.-llc 

Systein 

System 

The  pi  obtain  described  herein,  specifies  and  implements  a 
Plow  Modulator.  The  Plow  Modtdator  will  sequentially 
lead  a  message  in  mi  the  Piivate  System,  determine  wbrtiiei  that 
message  satisfies  an  appiopiiatr  Boolean  piedicale,  and  Based 
upon  the*  lesnlt.  will  eithei  H'h*a>e  the  iih-ssium-  |ti  the  Public 
System  or  will  log  the  reject  eel  iiii'ssiijm*.  So,  the  above  diagiam 
may  be  uiodiiied  slightly  to  the  following: 


Poi  the  pur]  loses  of  this  exposit  ion,  <h*l  ails  icspeet  ing  the  f«n 
mat  of  messages  and  the  detinition  of  the  Boolean  predicate  an* 
ignored.  Further,  it  is  specified  that  the  Modulator  will  process 
exact- ly  “number  j  if  -messages'*  messages  aiul  then  I  erminate.  It 
is  assumed  that  the  I/O  channel  types  are  of  (In*  same  kind. 

The  following  example  lias  broil  processed  hy  an  m  Verdi 
compiler  and  has  aiso  been  veritied  using  an  earliei  piototyjie  in 
FA  KS  v<*r  i  lien  t.  ion  system.  The  comments  of  the  hum  {!  ...  ( 
enclose  commands  which  arc  recognized  by  the  vei  ifiea  t  ion  sys 
t  cm  and  are  ns*.*  l  to  prove  the  pi  oof  obligations  arising  from  the 
associated  do  hunt  inns. 

The  program  is  liberally  sprinkled  with  remarks  which,  Iiope 
fully,  claiifv  aspects  of  t  he  problem  bring  solved  and  of  m  Venli. 
Only  that  text  wliieb  is  piintcd  in  typewriter  font  was  prr 
sent  ed  to  the  veiiiieation  system.  (Actually,  the  sequence  of 
declarations  was  presented  1  did  not  use  the  program  and 
environment  elm- »*s.  The  entire'  program  has  been  processed 
by  the  in  Verdi  r  >ih *r.) 

The  proginm  is  billed  “uiici oJlow -modulator.”  This  name 
has  no  ('fleet  on  the  vocabulary. 

program  micro.f lou_modulatoi  = 

The  environment  is  list'd  to  introduce  names  which  will  four, 
a  hid:  between  the  in  Verdi  program  and  t lie  observables  being 
modified.  It  also  hams  the  axiomatic  basis  for  the  piogtam. 
Then*  arc  no  (diu-ct)  proof  obligations  involved  for  thodevlara 
tit  ms  occurring  within  the  environment. 

environment, 

An  unspecified  executable  type,  called  “message”,  is  declined, 
in  this  instance,  a  pragma  is  used  to  indicate,  to  tin*  compiler, 
that  a  message  will  icquite  102*1  bytes  and  requires  a  particular 
word  oi  id, tat  ion. 

prog  type  message  = 

pragma  (alignment  *  lt  size  =  1024) 

The  following  sequence  of  decimations  inlioduce  a  theory  of 
sequences  of  messages  A  complete  theory  of  sequences  can  be 
quite  rich;  what  we  have  lieie,  however,  is  a  basic  kernel  of 
sequence  tlicoiy  concepts.  An  algebraic  datatype  style  of  pre 
sent  at  ion  has  b»*cn  Used  to  describe  i he  theory. 

The  tlicoiy  of  sequences  is  list'd  to  specify  (and  annotate)  our 
juograui.  ('lily  one  declaration,  that  foi  eOjnessage,  is  reqiiiied 
to  be  an  executable  dec  la  rat ion. 

type  sequence. message 

The  reader  should  be  aware  that  the  following  variable  d**cla 
ration,  and  all  subsequent  variable  dcclai  at  ions,  introduce  van 
able  symbols  to  the  vocabulary;  a  program's  stale  is  not  modified 
by  such  dedaiat ions. 


i'"'*li-i  should  In-  :iw:n<-  1 1 1:1 1  (In-  following  v;ni:ili|i-  .  1<  i1:i i ;i ( Ion.  :nul  ;ill  i.iili  .c'i|iii  nl 
v;> i i;il •].-  (Iiv|;iial ions,  iuliuclui  i  vnlialili-  symbol:.  to  tin-  Vm  almlaiy;  a  [it ogi .-mi's  slnli-  i  . 
Hot  Iiiiulllii-il  liv  Sill'll  ilivliil  at  inns. 

var  iO_mcsjsa£,e,  il.message ,  i 2_mossagc :  ini 

l'i  og  vai  eO.message:  message 

van  c  1  .massage  ,  c2_message :  message 

vai  sO.message,  sl.niessago,  s2_message :  sequenco.mossage 
const  empty.inossage :  scqucnce.messagc 


function  tack.message  (eO.message,  sO.message)  :  •lequor.cc.message 

function  he ad .message  (sO.message) :  message 
function  tail .message  (sO.messago) :  sequence.message 


axiom  pragma  (rule,  name  =  "head.tack. message") 
all  sO. message,  eO.message: 

head. message  (tack.message  (eO.message,  sO.messago))  =  oO. message 

axiom  pragma  (rule,  name  =  "tail.tack. message") 
all  sO.messago,  eO.message; 

tail. message  (tack.message  (eO.message,  so. message) )  =  sO.messagc 

axiom  pragma  (rule,  name  =  "scquencc.equality.message") 
all  sO.messagc,  si. message: 

implies  (and  (sO.messago  <>  empty. message , 
si. message  <>  empty .message) , 

(sO.messago  «  si. message)  = 

and  (head. message  (sO.moiisage)  »  licad.mos sage  (si .mensap.e)  , 
tail.message  (sO.message)  -  tail.mcssage  ( s 1 .message) ) } 

axiom  pragma  (rule,  name  =  "tack.equal.empty.mossage") 
all  sO. message,  eO.message; 

not  (tack.message  (eO.message,  sO.messagc)  =  empty.mossage) 


function  sizo.message  (sO.mossage)  :  ordinal 

axiom  pragma  (rule,  name  =  "size.t ail.message") 
all  sO.messago: 

implies  (sO.messago  cmpty.message, 

ordinal’ It  (size.messuge  (taii.tnossagc  (sO.message)  )  , 
size.messago  (sO.m-ssage) )) 

function  length.message  (sO.message):  int  = 
measure  sizo.mcssage  (sO.message) 
begin 

if  sO.message  -  empty  message 
then  0 

else  plus  (1,  length.message  (tail.mossage  (sO.message))) 
end  if 

end  length.message 


axiom  pragma  (name  *=  "length.is.non.negat jve.mossago") 
all  sO.message:  int’gc  ( length.mossago  (sO.message),  0) 
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axiom  p  agwa  (jul<j,  name  *  "1  ongt  h.tost.n'-eKflagc") 
all  i?0.rHisr.a^',  s 1 .message : 

implies  (1  engt  1*  .message  (sO. message)  <>  longt  (wl.nu’ssia^i’)  , 

not  (sO. message  *  ?  1. message) ) 


1  Ill*  I  *111  it  V'  "s  to  I  lie  end  i»i  \  lie  mm  jin  mi-  1  lit  ni  _\  Ivt  1 1  i*'l .  1 1 » slmv  t  lui  1  1  lii-  a  loirniri  it  1 1  'lift  I 
I  lift  ii  y  i  ■»  ft  *i  i-*ist  out  is  ;»  task  ilia!  1 1 1«  -  specihei  tif  t  lit*  jeul  ilen*  should  laikie.  ii«M  tin*  peiM»n 
\\lit»  lias  lift  *n  ptesented  with  ill**  spot  ilit  at  ion  and  told  tt»  iiiiplrjiienl  a  (wh«»-r 

sj'tviiit  at  mil  is  piesented  in  tonus  ol  sequence  tlieolN ).  loi  ceiuplel  I'urss,  1  hould  iiote 
llial  a  ii  a  it  1«  -I  Im  ilit*  l%fiiitl  lia**  hern  developed  (nang  in  \  \  l’.S)  aiul,  as  a  lesult  ,  the 
i\t‘i  iit'l  tlieoiy  is  fiiir  istt'iil 

The  unspecified  f  i  n  it  t  it  *|  i  “ok  will  he  t  he  fund  mil  Usrtl  to  check  that  nie-»*..iges  1 1 1 .  i  \  hr 
lrlrasrtl  to  I  Ilf  Public  system.  111  tills  tiisf,  fhrlt-  ait'  iu>  axioms  lost  i  irt  Hig  thr  po>sjh|r 
implement  at  ions  o|  “oh  .  Asa  consequence,  in  t  ho  ext  i  cine  oast*:,.  *\  ik"  oouhl  always  a-iuui 
tmo  t»i  al\va\s  leluin  la  1st  ami  still  satisfy  tho  iutoiil  <  »t  I  ho  specilieat  am. 


pt  og  i  unci  ion  ok  (oO .message 1 :  bool 

“ll  ill  nher.ol  ..messages"  is  to  l>o  usotl  as  tin*  constant  which  losliictc  th«*  uninhoi  ol  me. 
sagos  that  can  l»o  analyzed  h\  tho  pi  obtain,  The  axiom  specifies  that  tin-  vaiuo  mu-t  In- 
por.itivr  aiul  hounded  1 » y  uiaxiut.  Consequently,  any  implementation  of  t  he  onviiohmeul 
must  satisfy  this  loijuiiouioiii . 

pi  og  const,  numboi  .of  .messages :  int 

axiom  pragma  (name  *»  “about. number  _of  .messages" ) 
ami  (int’gt  (number .of .messages ,  0), 

iin.’gl  (maxuit,  number .of. messages) ) 


l’ho  following,  sequence  of  declm  at  ions,  thtnugh  to  tin*  oml  of  tho  oipii  onimni ,  lolato  to 
tho  ohsei cables  t*f  tho  ptogtaur  ami  how  thoy  nun  ho  modified  In  this  instance,  \w  have 
two  jirocoihuos  which  ;uo  usrtl,  rospoct  ively,  to  output  a  message  to  some  |>;u  t  n  ul  l i  pot  t 
(which  will  hr  eitliei  a  puit  linked  tt»  tho  Public  system  t>i  to  a  poit  lmhotl  to  t  lit*  ami  t 
lurchanism)  or  to  input  a  message  imni  tho  Plicate  systom. 

With  each  poit  wo  associate  a  histoiv  « »f  tho  messages  that  have  th»wrtl  thioiigh  tho 
port.  An  ah:.t  i  act  inn  function,  “pm  t  Jiislmv**,  is  used  to  captme  this  iiiiont  l-'ioin  the 
spi't-ilica!  ions  t»l  thr  pmceduies,  tho  trader  shtmltl  ho  ahlo  to  conclmlo  that  each  invocation 
o|  the  j»ri >ceduies  tosiilts  ill  tin*  pioressing  of  a  single  message. 


prog  typo  a.port  =  pragma  (alignment  *  1,  size  *  1024) 


prog  var  port:  a.port 

function  port. history  (port):  sequence.messagc 

piog  procedure  output. port  (invar  port,  lv.ir  oO.mosrago)  * 
initial  (port'O  =  port) 
pi o  true 

post  port. history  (port)  *  tack.niussage  (oO.messago ,  port.lii  story  (poit’O)) 

pi  og  pioccdure  input.port  (mvar  port,  pvar  e0_messago)  = 
initial  (poil’O  *  port) 
pro  t  rue 

post  port. history  (port)  =  tack_mer»sagc  (eO. message ,  port. history  (poit’O)) 
end  environment 

Many  of  the  declarations  that  follow  could  just  have  easily  heen  included  in  Hi.-  onv. 

I « >1111  lout  . 

The  following  sequence  nl  decimal  ions  are  int  her  speriiic  to  the  concept  of  mmluhuoi. 

1  hose  iloclai.it  ions  make  use  nl  the  sequence  tlieoiy  abstraction  to  captuir  inodul.it  oi 
CoiiC«*j»ts. 
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“accepted  .messages”  dotcnninc.s  (  lie  subsequence  of  sO .message,  preserving  order,  of  <1 
cincnts  that  satisfy  the  “ok”  predicate.  “n -jee  ted  _-i lcssagcs”  is  essentially  I  lie  same  function 
except,  that  it  ex  tl  ;u' t  s  the  elements  which  do  not  satisfy  the  “ok”  predicate. 

Since  hotli  these  functions  ate  defined  recursively,  we  must  show  that  they  do,  ill  fact., 
describe  some  function.  See  |Saa  87]  for  the  pioof  obligations  arising  from  rornrswe  fiuie 
t.ion  definitions.  Further,  ill  both  instances,  a  leiiuna  was  required.  The  lirst  step  in  each 
proof,  introduces  the  lemma  “length jsjioiuiegativc .message”.  The-  second  step,  prove, 
results  ill  m  Never  applying  its  rewriting  and  simplification  techniques  to  reduce  the  for 
inula  to  true. 

function  accepted. messages  (sO. message) :  sequence.message  = 
measure  ordinal’ val  (length.message  (sO.message) ) 
begin  if  sC.message  =  empty.message 

then  empty.message 

elseif  ok  (head.message  (sO.message)) 

then  tack.mersage  (head.message  (sO.message) , 

accepted. messages  (tail.message  (sO.message))) 
else  acccpted.raessages  (tail.message  (sO.message))  end  if 
end  accepted.raessages 

{ !  use  "length.is.non.negative.message"  } 
f  !  prove  } 

function  re j ected.messages  (sO.message):  sequence.message  ~ 
measure  ordinal’val  (length.message  (sO.message)) 
begin  if  sO.message  =  empty.message 

then  empty.message 

elseif  not  (ok  (head.message  (sO.message))) 
then  tack.message  (head.message  (sO.message), 

rejected.messages  (tail.message  (sO.message))) 
else  rejected.messages  (tail.message  (sO.message))  end  if 
end  rejected.messages 

{ !  use  "length.is.non.negative.message"  } 

{  !  prove  } 

The  following  fund  inn  is  a  be  ml  predicate  which  specifies  that  every  dement  of  a  se¬ 
quence  must,  satisfy  the  "ok"  predicate.  The  axiom  that  follows  then  states  that  seen 
lily  .properly  holds  over  the  sequence  returned  by  accepted  .messages.  This  is  a  rather 
trivial  example  of  a  proof  of  a  specification  piopcrty.  Observe  that  the  proof  of  "nr 
coptrdjmcsK!tgr.,soqueiicr_is.,sorurr”  uses  automatic  induct  ion. 

function  security. property  (sO.message)  :  bool  = 
measure  ordinal’val  (length.message  (sO.message)) 
begin  if  sO.message  =  empty.message 
then  true 

else  and  (security.property  (tail.message  (sO.message)), 
ok  (head.message  (sO.message))!  end  if 
end  security.property 

{!  use  "length.is.non.negative.message"  } 

{ !  prove  } 

axiom  pragma  (name  =  "accepted.message .sequence.is. secure") 

all  sO.message:  security.property  (accepted .messages  (sO.message)) 

{ I  prove.by.induction  } 

The  following  three  variable  names  will  be  used  as  formal  parameters  to  the  main 
program  and  will  he  dliertly  related  to  ports  ovri  which  messages  How  to  tin-  l’uli 
lie  system,  to  the  audit  mechanism,  and  ftoqi  the  I’nvate  system,  n-spee1  ively.  "until 
her.of  jiiessagesj  i-ad”  will  he  used  within  tin-  main  program  to  define  a  component  of  the 
pliigiaiii’s  stale  and  will  he  used  its  a  counter  for  the  number  of  messages  lead  to  some 
point  in  t  line. 

prog  var  down,  reject,  input:  a.port 
prog  var  number.of.mcssages.read :  jnt 


Tin-  following  three  functions  are  used  to  specify  and  annotate  the  mail)  program. 

function  precondition  (down,  r- ject,  input):  bool  = 
begin  and  (port.history  (down>  =  empty. message , 

port. history  (reject)  -  empty. message, 
port.history  (input)  =  empty.message) 
end  pre.condi tion 

function  post.condition  (down,  reject,  input):  bool  = 
begin  and  (port.history  (down)  = 

accepted.messages  (port.history  (input)), 
port.history  (reject)  = 

re jected.mes sages  (port.history  (input)), 
length. message  (port.history  (.input))  = 
number .of .messages) 
end  post.condition 

function  loop.invariant 

(down,  reject,  input,  number.of.messages.read) :  bool  = 
begin  and  (port.history  (down)  = 

accepted.messages  (port.history  (input)l, 
port.history  (reject)  = 

rejected.messages  (port.history  (input)), 
length.message  (port.history  (input))  - 
number.of.messages.read , 

int’ge  (number.of .messages ,  number_of..messages_read)  , 
int’ge  (number.of.messages.read,  0)) 
end  loop.invai iant 


main  procedure.  The  ir 


j:.  fairly  :.tvuightforv/:ird.  The  pnief 


of  the  procedure  required  two  lemmas,  including  one  referring  to  minint  and  maxiiit,  viz. 
‘•MINI N'T  AND  MAXINT  RKQUIUEMENTS”.  The  Vq.,  •lity.substiiuie"  step  results  in 
the  replacement  of  “p  .  Jiistorvf  input '1 )’’  hy  an  expressio  it  is  equated  with.  As  a.  point 
of  interest,  in  a  litter  version  of  the  system,  when  the  prover  had  heen  augmented  with 
fm  ward  rules,  the  proof  of  the  main  procedure  was  reduced  to  three  steps  since  the  lemmas 
did  not  have  to  he  explicitly  assumed. 


main  prog  procedure  flow.modulator  (mvai  down,  mvar  reject,  mvar  input.)  = 
pre  pre.cond ition  (down,  reject,  input) 
post  post.condition  (down,  reject,  input) 
begin 

pvar  eO.message 

pvar  number.of.messages.read  :=  0 
loop 

invariant  loop.invariant  (down, 

reject , 
input , 

number.of.messages.read) 
measure  ordinal’ val  (minus  (number.of .messages , 

number.of.messages.read) ) 

exit  when  number.of.messages.read  =  number.of .messages 
input.port  (input,  eO.message) 

number.of.messages.read  :=  eplus  (number.of.messages.read,  1) 
if  ok  (eO.message) 

then  output.port  (down,  eO.message) 
else  output.port  (reject,  eO.message) 
end  l  f 
end  loop 

end  flow.modulator 

{!  use  "about.number.of .messages"  } 

fi  use  "MI N INT- AND-MAXINT-REQU1 REMENTS"} 

{ !  prove  ) 

{!  equal ity.substitute  port.history  (input’l)  } 

1  1  prove  } 


end  micro.f 1 ow.modul ator 
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The  Bell-LaPadula  Computer  Security  Model 
Represented  as  a  Special  Case  of  the 
Harrison-Ruzzo-Ullman  Model 

Paul  A.  Pittelli 


ABSTRACT 

Currently  most  computer  security  models  are  classified 
among  the  three  types;  access  control,  information  flow,  and 
non-interference.  Within  the  realm  of  access  control  lies  the 
classical  Bell-LaPadula  model.  A  BLP  model  consists  of  a  set  of 
subjects  and  objects,  three  security  level  functions,  and  a 
discretionary  access  matrix  together  with  a  set  of  rules  used  to 
manipulate  the  current  state  of  the  model.  Security  in  this 
model  is  dependent  upon  the  satisfaction  of  the  three 
properties:  simple  security,  discretionary  access,  and  the  * 
property.  An  HRU  model  consists  of  an  access  matrix  and  a 
finite  set  of  commands  which  act  as  matrix  transformations. 
Here  security  is  determined  by  looking  for  the  existence  of  an 
access  right,  in  a  specific  cell  of  the  matrix  We  define  3  specific 
HRU  model  (called  the  Bobo  model)  and  establish  a 
correspondence  between  the  Bobo  commands  and  BLP  rules, 
also  between  the  Bobo  and  BLP  states  Furthermore  we 
observe  that  this  correspondence  is  security  preserving  in  the 
fact  that  a  BLP  access  triple  is  secure  if  and  only  if  that  access 
is  contained  in  a  specific  ceil  of  the  Bobo  access  matrix. 


Introduction 

The  purpose  of  this  note  is  to  show  that  the  Bell-LaPadula 
model  for  access  control  is  simply  a  special  case  of  the  not  so 
well  known  Harrison-RuzzoU  liman  model.  The  HRU  model 
consists  of  an  access  matrix  together  with  a  finite  set  of 
commands  that  are  used  to  manipulate  the  matrix.  In  order  to 
develop  a  model  equivalent  to  BI.P's,  we  need  to  exhibit 
commands  that  are  "identical"  to  the  BLP  rules 

Before  wc  begin  defining  the  commands,  we  must  first 
exhibit  a  correspondence  between  the  "subjects”  and  "objects" 
in  the  BLP  model  and  the  "subjects"  and  "objects”  in  the  HRU 
environment.  The  reason  for  the  above  quotes  is  that  subjects 
and  objects  are  disjoint  sets  in  BLP,  whereas  the  set  of  subjects 
is  contained  in  the  set  of  objects  under  HRU  This  distinction, 
though  seemingly  small,  is  well  worth  remembering  However, 
a  key  factor  of  the  BLP  model  is  the  use  of  the  functions 
fs,f,  .and  (q.  These  functions  associate  a  security  value  to  a 
subject  or  object,  which  allows  one  to  compare  subjects  to 
objects. 

The  preceeding  paragrapn  indicates  some  of  the  diffeiences 
we  need  to  consider  when  relating  BLP  to  HRU  The  major 
concept  in  this  new  model  is  the  notion  of  a  subjectiobjert) 
represented  by  a  set  of  entities.  Defining  a  subject  as  a  set  of 
sub  subjects  allows  us  to  implement  the  multilevel  capabilities 
of  a  BLP  subject  in  an  access  matrix  Likewise  an  object  viewed 
as  a  set  permits  the  use  of  an  upgrade  command 


Specifically,  suppose  we  have  a  BLP  model  which  consists 
of  the  following  entities, 

X  -  js,  1  =  1,2,  ,k}  —  set  of  subjects 

f)  —  jo;  j  1 ,2,  ,n}--  set  of  objects,  recall  ii  n  0  ~  0 

L  =  {1,  t  =  0,1 ,  ,T)  --set  of  security  values  forming  a 
lattice  under  the  partial  ordering  referred  to  as  the 
dominance  relation  Without  loss  of  generality  let  1q  anil 
ly  denote  the  least  upper  bound  of  L  and  the  greasiest 
lower  bound  of  I.  respectively. 

fS:£  =>  L  -  function  yielding  the  maximum  security 
level  for  a  subject. 

fc:£  =>  L  -  function  yielding  the  current  security  level 

*vi  auuji-u.. 

fo  0  =>  L  -  function  yielding  the  security  value  of  an 
object. 

R  =  {append, write, read, execute)  •  set  of  access  rights. 

M  =  k  x  n  matrix  with  m,j  C  R  representing  the  set  of 
discretionary  access  rights  that  subject  s,  has  to  object  Oj 

We  now  begin  showing  how  to  incorporate  the  BLP 
model  into  an  HRU  environment.  First  we  define  the  following 
components  of  an  HRU  model: 

S  =  {s,!t  s,E  b  and  i  c  ST,}  U  {sqIt'i  Corresponding  to  each 
BLP  subjects,  is  a  subset  S,  ofS,  where  S,  =  {s,lt  t  c  ST,), 
which  represents  s,  together  with  all  of  s,'s  allowable 
security  values.  That  is  {lt.  te  ST,}  =  {lt  c  L  fs(s,)  i>  1J 
Formally  the  elements  of  S,  come  from  the  cross  product 
space  X  x  0,  but  for  eBse  of  notation  wc  will  write  the 
elements  as  Sjlt.  Thus  Sjlt  will  denote  an  HRU  subject 
Furthermore  we  reserve  the  subject  Soh  to  be  a  system 
subject.  Thus  So  =  {solr)  and  STo  =  {T}  The  pin  pose  of 
Sgi’r  is  to  let  the  system  know  at  what  level  an  object  is 
currently  classified  as  will  be  formalized  later 

O  =  S  U  6  where  0  =  {oj  1  u :  Oj  e  0  and  u  c  OTj)  We  relate 
to  each  object  Oj  a  set  of  values  (lu  u  e  OTj)  wh.ic  i 
represents  all  the  security  values  that  ot  could  assume. 
That  is  {lu:  u  c  Olj)  =  {lu  z  L.  1„  t>  fo(Oj)}. 

A  =  {active, own, r,a,w,e)set  of  generic  access  rights 

P  -  (P[s,ol),  p  x  (p  -t-q)  matrix  where  P|s,ol  C  A  for  s  t  S 
and  o  e  0.  Here 


k 

•1 

ST 

l 

and q  -  ^ 

or 

j 

1  -0 

P  is  simply  referred  to  as  the  access  matrix 


J  1  8 


Primitive  Operations: 

In  the  HLP  model  the  rules  allow  for  t lit  creation  and 
deletion  of  objects  as  well  as  the  insertion  and  removal  of  an 
access  right  from  a  cell  in  the  access  matrix  M  In  the  HRU 
model  there  are  counterparts  of  these  actions  which  are  termed 
primitive  operations  Because  of  our  particular  example  there 
is  an  additional  operation:  delete  a  proper  subset  of  the  set  Oj  = 
{ojlu.  u  e  CTj}.  This  last  primitive  operation  will  provide  the 
means  to  implement  an  upgrade  command. 

Given  system  state  (S.O.P)  we  define  a  primitive  operation  op 
as  a  function  op:(S,0,P)  (S*,0*,P*)  where: 

(1 )  op  =  create  object  OjlUl 

where  Oj^  0  We  have  for  all  1  P  10; 

S*  =  S,  0*  =  O  U  {Ojl}, 

P*[s,ol  =■  Fls.ol  for  all  (s,o)  e  S  x  O 
P*(3,0jJ]  =  0forallseS. 

(2)  op  =  delete  object  Oj, 

where  OjC  0\S  We  have  for  all  lc  L; 

S*  =  S,  0#  =  O\{0jlf. 

P*[s,ol  =  Pls.o]  for  all  (s,o)  c  S  x  0* 

(3)  op  =  delete  objects  Ojlu, 

where  ojlu  f.  0  \  S.  We  have  for  all  1  if  lu, 

S*  =  S,0*  =  O\{ojl}, 

F^s.oj  =  P(s,o]foi  all  (o,u)  t,  3  a  0*. 

(4)  op  =  enter  x  into  PlS„o.lttJ, 

where  x  r  A,  S,  C  S,  and  Ojlu  e  O  \  S.  We  have  for  all  l,lt 
with 


if 

x-r 

if 

x  -  w 

lpl' 

if 

x  -  a 

lt  =  lT 

if 

x  =  active 

0 

if 

x  ~  e  or  own 

S*  =  S.O*  =  0, 

P*l»,oJ  -•  Pls.o)  for  all  (s,o)  *  (stlt,Ojl) 

P*lsilt,Ojll  =  Pls.U.Ojll  U  {x}. 

(5)  op  -  delete  xfrom  P[Si,0|lulv 

where  x  e  A.  We  have  for  all  l,lt  with  lu  P  l, 

S*  =  S,0*  =  0, 

P*ls,oJ  =  P[s,o}  for  all  (s,o)  *  (s^.Ojl) 

P*[s,it,0|l]  =  P[s,li,Ojll \{x}. 

As  an  aid  to  understanding  the  effects  of  the  primitive 
operations  on  the  matrix  P,  it  is  helpful  to  consider  that  there 
corresponds  to  each  subject  .object  pair  (s,,Oj)  p  submatrix  P(J 
whose  rows  are  indexed  by  ST,  and  whose  columns  are  indexed 
by  OTj.  The  consequences  of  applying  the  primitive  opei  aliens 
can  be  summarized  as  follows. 

(l)op  r  create  object  Ojl u 

This  operation  ci  cates  a  set  of  matrices  o  s  i  ■?  n}. 
where  P(J  has  rows  corresponding  to  elements  in  NT,  and 


columns  corresponding  to  the  members  of  OT,  The  cell- 
of  each  submatrix  are  all  empty 

(2)  op  -  delete  object 

This  operation  removes  from  the  matrix  P  all  those 
subm&trices  Py  for  0  5  i  5  k.  Recall  that  k  is  the 
cardinality  of  S,  the  set  of  BLF  subjects. 

(3)  op  =  delete  objects  Ojlu 

This  operation  removes  a  subset  of  columns  from  each 
matrix  Py,  0  i  i  S  k,  specifically  all  those  columns 
corresponding  to  ojl  where  1  f*  lu. 

(4)  op  -  enter  x  into  PlGl,oJlu] 

This  operation  inserts  x  into  a  subset  of  positions  of  the 
matrix  Py  defined  by  the  various  values  of  x. 

(5)  op  =  delete  x  from  P|Si.0jlu] 

This  operation  deletes  x  from  all  entries  in  those  columns 
of  Py  corresponding  to  1  where  la  P  1. 

Commands: 

An  MRU  command  is  simply  a  conditional  IF  (expression 
1)  THEN  (expression  2)  where  expression  1  is  a  boolean 
function  and  expression  2  is  a  sequence  of  primitive  operations. 
To  implement  the  Bl.P  model  in  an  HKU  environment  we  will 
use  the  following  commands.  For  ease  of  notation  let  Sr  = 
requesting  subject  and  x  a  member  of  the  set  {r.a.w.e}. 

(1)  Command  01  VK(Sr.Si,x,Ojlu) 

IF  own  e  Plsrit,Ojiul  for  any  lt,  and 
active  e  PUo1t,°jU 

THEN  enter  x  into  PIS„OjIt1- 

(2)  Command  RESClNl)(SriS,,x,Ojiu) 

IF  own  c  Plsrlt,Ojlu]  for  any  lt 
THEN  delete  x  from  PlS„Ojlu). 

( 3 )  Co  m  m  a  nd  C  F,  N  K  R  A  T  E  ( Sr ,  Ojl  u ) 

IF  TRUE 

THEN  create  object  Ojlu, 

enter  active  into  P(So,Ojlu], 
enter  own  into  PlSr,Ojl  i  1. 

(4)  Command  DKSTROYlSr,Ojlg) 

IF  own  e  Pisrb.ojlu!  for  some  b 
TH  EN  delete  object  Oj. 

(5)  Command  CPGRAI)K(SriOj,lUot1U|) 

IF  own  e  1’lSrU.OjluJ  for  some  It,  and 
active  e  Plsoh*.OjluJ 

THEN  delete  objects o,l U], 

enter  active  into  P|So,nJlUj  j 

Note  For  the  rest  of  this  paper  the  sets  S,  0,  access  matrix  P. 
and  the  five  commands  defb  ed  above  will  comprise  that  which 
will  he  called  the  Bobo  model 


Equivalence  to  HE P: 

The  method  that  we  will  use  to  exhibit  an  equivalent-.- 
between  the  B1,P  and  Bobo  models  is  a  two  fold  process  Fir-’ 
we  will  piuve  a  theorem  that  will  show  every  state  of  a  Bl.P 


model  is  achievable  by  tin*  Hobo  model  Secondly  a 
correspondence  between  the  stale  transition-  of  the  two  models 
will  he  drawn  by  simply  listing  each  Hid*  state  transition 
together  with  its  counterpart  Hobo  state  transition. 

Besides  showing  that  every  BLF  state  is  achievable  by 
the  Bobo  model,  the  theorem  below  illustrates  how  to  identify 
the  BLP  set  of  secure  access  triples  in  the  HRU  environment. 
One  of  the  hypotheses  of  the  theorem  is  an  assumption  on  the 
initial  access  matrix  P°.  Wl*  assume  that  for  0  ^  i  ^  k, 

1  <,  j  £  n,  t  c  ST,;  u  e  OTtl 

f  {active}  ifs  -  standi  = fJio .) 

»  0  U  •o  J 

{own}  ifs  crectcdo 

i  j  f  t  j 

0  otherwise 

In  order  to  sec  that  this  is  not  an  unreasonable  assumption, 
consider  what  happens  when  we  generate  an  object  Oj  Suppose 
in  the  BLF  model  subject  Si  created  object  oj  at  level  fo(Oj)  =  lu 
In  the  Bobo  model  this  is  accomplished  by  issuing  the  command 
GENEKATK(Si,Ojlu).  Upon  execution  of  the  command  we  see 
that  the  submatrices  PttJ  are  all  empty  except  when  a  =  i  in 
which  the  matrix  P,,c<  gains  {own}  in  every  cell.  Also  there  is 
only  one  entry  in  Fqi  which  is  nonempty  and  that  is 
P0( SolT.Ojfo(°jll  -  {active}.  Thus  we  see  that  if  the  system 
knows  who  created  each  object  then  we  can  generate  the  initial 
matrix  PO  by  a  sequence  of  GENERATE  commands.  Hence  our 
assumption  on  the  matrix  PO  can  be  made  without  loss  of 
generality. 

Theorem  Let  M,f  be  a  state  of  a  BI.P  model  with  subjects 
{si,&2.---i*m}  anc*  objects  {oi.02,  ,on}.  Let  p  be  the  set  of  all 

possible  secure  triples  (s,o,x)  completely  determined  by  M  and  f. 
Define  a  Bubo  access  matrix  P°  to  be,  for  0  £  i  ^  k;  1  ^  j  ^  n; 
ttSl’,;  uc  OT,; 

{active}  ifs ^  *=  $Qandtu  = 
PyWJ--  ^  {own}  ifsicrvatedoj 
0  otherwise 

Then  there  exists  a  sequence  of  commands  ci,C2,  Xk  such  that 
iS°.O°.P0)=><SliO»(Pl)  *  .=KSk,Ok,Pk)  Und  (s.o.x)  c  P  O  x  e 
Pklsfc(S),of0(o)J. 

Pf  For  every  object  Oj  we  perform  the  following 
Suppose  sti  is  the  creator  of  Oj, 

then  for  all  x  c  m,j  issue  the  command 
GlVKtSd.Sj.x.OjfotOj)),  fori=  1,2,  ,m. 

Since  the  set  of  subjects,  objects,  and  access  rights  are 
finite  sets  then  we  have  generated  a  finite  sequence  of 
commands  say  Ci.^-.-Cfc  which  transforms  (SO, 00,1*0)  =* 
(Sk.Ok.Pk), 

Claim  (s.o.x)  c  p  <>  x  e  Pk[sfi;(s),ofo(o)l. 

Pf:  Supposes, cp  « 

(  f^s)  >>  fQ(o)  and  (Q{s)  S>  fQ{o)  if  x  =  r 

j  fs'5? p  fo(aj]  and  4<s,) = vv if  x  =  w 

xe m  and  N  ^ 

"  |  foV^W'f  *  =  a 

if  x  - 

GIVEtS^.Sj.x.OjfytOj))  is  executed,  where  sj  is  the 

creator  of  Oj 
X  t  Pk|  S|f(j(Sl)>Ojf()(U|)|.  • 

Now  we  need  to  show  that  all  the  possible  state 
transitions  in  the  BI.P  model  are  attainable  in  this  new  setting 
Kc feiiing  to  Ml  we  find  l ha*  them  are  11  state 
trans  i  1 1  oust  rules)  For  each  rule  we  will  establish  an 
equivalent  command  and/or  a  reason  why  the  rule  is  sat  isfied 


Rules  1-5:  get, release  read/append/wri te/exccute 

It  is  unnecessary  to  implement  a  get  or  reiiase  command 
in  our  Bobo  model  In  BLP,  a  subject  has  to  request  get  access 
to  an  object  so  that  the  *  property  is  never  violated  However  in 
the  Bobo  model  the  enter  access  primitive  operation  assures 
that  the  *  property  will  not  be  violated  Thus  a  subject  in  the 
Bobo  model  obtains  access  to  an  object  whenever  the  owner  of 
the  object  has  given  him  the  desired  access  by  executing  a 
GIVE  command. 

Rule  6:  give  -  read/append/writc/execute 

This  rule  corresponds  to  the  command  GIVE.  The  rule 
checks  to  see  if  the  requesting  (giving)  subject  has  the 
authority  to  "give"  another  subject  access  to  a  specific  object 
This  is  accomplished  by  the  command  via  the  condition  that  the 
requesting  subject  haveMownership"  of  the  object  in  question 
Furthermore  upon  a  true  condition,  the  given  access  right  is 
granted  so  that  the  BLP  *  property  is  not  violated,  (e  g.  If  s,  is 
granted  w  access  to  o,,  then  w  is  only  added  to  the  set  in 
positions  (s,lt,0jlt)  for  all  te  OT,.) 

Rule  i  rescind  ■  read/appcnd/write/execute 

The  command  KKSC1N1)  performs  the  inverse  of  GIVE 
as  does  the  rule  rescind  in  the  BLP  sense.  Again  the  condition 
tests  the  authority  of  the  requesting  subject  vie  “ownership" 
and  upon  valid  authority  removes  the  specified  access  from  the 
subject’s  access  columns. 

Rule  8,9  create, delete  object 

Cotnnmnds  GENERATE  and  DESTROY  correspond  to 
the  rules  create  and  delete  resnertively  GENERATE  creates 
an  object  and  defines  the  initial  "owner"  of  the  object  to  be  its 
creator.  DESTROY  checks  for"owncrship”  for  authority  to 
delete  the  object  from  the  system. 

Rule  10:  change  subject-current-sccurity  level 

There  is  no  need  for  a  command  which  changes  a 
subject's  current  security  level  The  reason  is  that  the  Bobo 
model  defines  a  subject  S,  to  be  the  set  {s,lt:  t  c  ST,}  This  allows 
a  subject  to  work  on  an  object  Ojly  in  mode  x  if  and  only  if  there 
is  some  t  e  ST,  such  that  x  e  Fls.lt.OjiJ.  Thus  the  command 
automatically  changes  a  subjects  current  security  level  to 
accomodate  the  desired  access  to  an  object 

Rule  11:  change  object  security  level 

The  command  UPGRADE  performs  the  function  of 
changing  the  security  level  of  an  object.  Ir.  BLP  the  reference 
monitor  needs  to  verify  that  the  new  level  is  a  valid  one  and 
that  the  requesting  subject  has  the  authority  to  change  the 
function  f<j.  This  is  accomplished  by  the  "own”  access  right  and 
the  delete  objects  primitive  operation.  Furthermore  suppose 
thut  object  Oj  gets  upgraded  from  level  lu  to  lv.  Notice  that 
because  of  the  primitive  operation  enter,  if  subject  s,  had  access 
x  to  Ojla  then  s,  will  still  have  access  x  to  0,1  v  provided  thut  the  * 
property  is  not  violated  This  implies  that  :he  UPGRADE 
command  automatically  cancels  all  current  accesses  thiit 
violate  the  *  property  at  an  objects  new  security  level 


Komarks: 

Even  though  the  Bobo  model  can  simulate  the  BLP 
model,  there  are  several  characteristics  that  have  been  create*’, 
to  accomplish  this  The  first  and  most  important  is  the  m*i\ 
idea  of  an  access  right  called  "own”  The  BLP  model  contains  a 
tree  structure  for  the  objects  called  a  hierarchy  However  the- 
hierarchy  of  objects  is  not  related  to  l tie  seem  it y  of  the  mode* 


Inil  exists  merely  because  of  the  application  of  Ill/I*  to  the 
Multics  system  Thus  we  see  that  the  only  concept  of  ownership 
of  an  object  in  HI -I*  lies  in  I  he  (live  fynction  for  ruin  6.  In  order 
to  implement  this  Give  function  it  is  necessary  to  use  an  "own” 
access  right.  The  Bobo  model  is  conservative  in  the  fact  that 
the  only  subject  who  can  have  ''own”  access  to  an  object  is  that 
object’s  creator.  However  if  there  is  need  for  group  ownership  of 
an  object  the  conditions  of  the  GIVE  command  car.  be  changed 
to  accommodate  thi3  feature 

The  other  new  access  right  in  the  Bobo  model  is  ’’active”. 
The  purpose  of  "active”  is  simply  to  let  the  reference  monitor 
know  the  current  level  of  an  object.  This  feature  then  allows  for 
the  upgrading  of  an  objects  security  level. 

The  use  of  sets  for  representing  subjects  and  objects 
creates  more  responsibilities  for  the  reference  monitor  in  the 
Bobo  model  In  particular,  since  a  subject  can  work  at  any  level 
he  dominates  and  an  object  can  assume  various  security  values, 
then  it  should  be  the  job  of  the  reference  monitor  to  inform  the 
subject  at  what  level  he  is  working  and  the  value  of  the  object 
that  he  is  accessing. 

The  last  remark  that  we  want  to  make  concerns  the  form 
of  the  access  matrix  P.  The  easiest  observation  to  make  is  that 
the  submatrix  whose  rows  and  columns  are  indexed  by  the 
subjects  is  completely  empty.  This  reflects  the  fact  that 
subjects  are  not  allowed  to  access  other  subjects  in  the  Bid* 
model.  Also  the  method  of  giving  subjects  access  rights  creates 
alotof  redundant  information  That  i  •,  if  the  reference  monitor 
wants  to  check  to  see  if  subject  s,  has  access  x  to  object  Ojlu  then 
the  only  cell  necessary  to  examine  is  Pl$|lu,Ojlu]. 


Safety: 

This  section  discusses  the  concept  of  safety  as  introduced 
by  Harrison,  Ruzzo  and  Ullman.  Intuitively  a  "safe”  security 
model  (i.e.  protection  system  in  HRU  terminology)  is  one  which 
will  not  allow  unauthorized  access  to  objects.  The  following 
two  definitions  formally  state  the  idea  of  safety. 

Def:  G  iven  a  protection  system,  we  say  a  command  a 
leaks  generic  right  r  from  configuration  Q  =  (S,  O,  P) 
if  «*,  when  run  on  Q,  can  execute  a  primitive 
operation  which  enters  r  into  a  cell  of  the  access 
matrix  which  did  not  previously  contain  r. 

Def:  Given  a  particular  protection  system  and 
generic  right  r,  we  say  that  the  initial  configuration 
Q0  is  unsafe  for  r  (or  leaks  r)  if  there  is  a 
configuration  Q  and  a  command  «  such  that 

(1)  Qo  =>  Q  by  a  sequence  of  primitive  operations, 

(2)  «  leaks  r  from  Q. 

The  first  observation  one  can  make  is  that  any  system 
which  utilizes  the  primitive  operation  enter  will  most  likely  be 
deemed  unsafe.  Harrison  et  al.  make  the  convention  that  to 
check  for  unauthorized  leakage,  we  need  to  eliminate  from 
testing  those  subjects  who  are  actually  authorized  to  give  (leak) 
rights.  They  use  the  term  "reliable"  subjects  to  mean  the  set  of 
subjects  who  are  authorized  to  grant  the  genet  ic  right  r  of  an 
object  to  another  subject. 

The  general  question  of  whether  or  not  an  arbitrary 
protection  system  is  safe  was  shown  to  be  undccidable  by  H1U: 
However  if  a  specific  model  consists  of  commands  which  involve 
only  one  primitive  operation  (mono  operational  in  IlKl* 
terminology)  then  the  question  of  safety  is  decidable  Our  Bobo 
model  happens  to  live  in  the  middle  ground  of  the  previous 


sentence*  That  is,  the  Holm  model  is  not  ,i  mono  operation 
system  but  we  will  show  that  the  model  is  "safe” 

Its  not  too  hard  to  see  that  every  command  except  the 
GENERATE  command  contains  a  check  for  ownership  in  the 
condition  Since  a  subject  who  owns  an  object,  is  deemed 
reliable  then  the  only  command  in  question  is  the  GENERATE 
command.  However,  anyone  who  creates  an  object  is  by  nature 
reliable  with  respect  to  that  object  So  we  can  view  the  entering 
of  the  own  access  right  by  the  creator  of  the  object  giving 
himself  access  Therefore,  all  the  commands  in  the  Bobo  mode! 
preserve  safety  which  implies  the  Bobo  model  is  itself  "safe”. 


Conclusions: 

Besides  an  attempt  at  unifying  pome  of  the  existiiiv 
access  control  models,  the  Bobo  model  reveals  an  interesting 
point.  This  is  we  sec  that  the  HKU  model  is  a  very  general 
access  control  model  Moreover  one  can  appreciate  the  elegance 
of  the  model  by  the  fact  that  the  complex  BLP  model  can  be 
defined  by  an  access  matrix  together  with  a  set  of  five 
commands.  Being  able  to  incorporate  the  three  functions  fs,  fCl 
f0,  the  BLP  discretionary  access  matrix  M,  and  the  set  of  all 
current  accesses  b  into  the  matrix  P,  allows  one  to  see  the 
interplay  between  the  different  security  levels  and  the  * 
property  Also  note  that  we  have  only  dealt  with  the  rules 
defined  by  volume  4  of  the  Bell  LaPadula  model.  A  current 
topic  of  discussion  is  whether  or  not  the  rules  constitute  a  part 
of  a  BLP  model.  This  is  no  concern  of  this  paper  so  we  do  not 
attempt  to  imply  either  case  However  what  we  show  is  how 
the  rules  of  any  BI/P  model  correspond  to  commands  in  an  HKU 
inodei.  Thus  if  any  more  rules  ait-  auued  tv  the  existing  Bl.P 
model  then  a  new  command  can  be  added  to  the  Bobo  model 
accordingly  in  Older  to  preserve  the  equivalence.  Even  though 
implementation  of  the  HUP  model  might  be  simplified  by  using 
the  3obo  model,  the  intent  of  this  paper  and  follow  ons  is  to  try 
to  unite  all  the  existing  access  control  models  in  one 
framework;  maybe  that  of  the  Harrison,  Ruzzo,  tJllman  Model. 
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The  Gypsy  Verification  Environment  (GVE)'2  is  one  of  two 
systems  endorsed  by  the  National  Computer  Security  Center  (or  use  in 
meeting  the  verification  requirements  tor  an  A1  level  evaluation  as 
outlined  in  the  Trusted  Computer  Systems  Evaluation  Criteria*. “  Gypsy 
has  been  used  extensively  in  secure  systems  specification  and 
verification  project?  including  the  Encrypted  Packet  Interface4,  Message 
Flow  Modulator1’.  Honeywell  SCOMP8.  Honeywell  SAT7,  and  ACCAT 
Guard8,  The  Boyer  Moore  theorem  prover  has  also  seen  extensive  use 
in  the  security  arena  It  lias  been  used  as  a  component  of  the  HDM 
verification  system9  on  KSOS10,  SCOMP,  and  SACO  IN". 

Yet  the  ways  in  which  these  two  systems  are  currently  used  in 
secure  system  development  efforts  are  quite  different.  The  GVE  is 
utilized  as  a  fully  integrated  verification  environment  The  Gypsy 
language  is  used  for  constructing  code  and  specification,  verification 
conditions  are  generated  and  proved  in  the  GVE  proof  checker;  and,  in 
some  cases,  fhe  Gypsy  code  is  compiled  and  run.  The  Boyer  Moore 
system,  on  the  other  hand,  is  used  only  as  the  proof  checker  for 
verificalion  conditions  generated  from  specifications  written  in  some  high 
level  lanoi1'  a  such  as  Special  This  is  true  desprie  the  fact  that  the 
Boyer-Mo..  logic  contains  a  fully  executable  functional  programming 
language  The  Boyer-Moore  system  has  been  used  not  only  to  state  and 
prove  theorems  in  traditional  mathematical  domains  such  as  number 
theory  and  recursive  function  theory,  but  also  to  specify  and  prove  the 
correctness  Ot  a  microprocessor'2,  arid  is  being  used  to  prove  the 
correctness  of  an  operating  system  and  a  compiler'3.  A  main  contention 
of  this  paper  is  that  the  Boyer-Moore  logic  can  also  be  used  effectively 
as  a  specification  language  for  secure  systems,  particularly  at  the  model 
level. 


This  paper  investigates  the  viability  of  the  Boyer-Moore  logic  as  a 
specification  language  for  secure  system  modeling  efforts  by  comparing 
it  to  Gypsy  on  a  significant  example.  The  example  wo  etiose  was  the 
Low  Water  Mark  llem.  a  simple  secure  system  which  has  been  used 
in  two  differ*?  s  t,'4- 15  for  comparing  verification  systems  At  least 

three  differed  -y  specifications  for  this  problem  have  been 
published'4- 16  '  soecirication  ditlers  from  each  ot  these  Using  a 
non  interference  1  Laiscterization  of  security,  we  specified  the  Low 

Water  Mark  syste.  Gypsy  and  in  the  Boyer  Moore  logic.  The  key 

security  theorem  was  proved  in  each  system  using  the  associated  proof 
checker.  We  compare  the  specifications  and  proots  in  the  two 
languages,  point  out  tha  "  '  -antages  and  disadvantages  of  each  system, 
and  investigate  the  pc  .'ility  of  defining  a  hybrid  language  which 
combines  most  of  tho  adv  .itages  ot  each. 


'  TWO  LANGUAGES 


Gypsy 

Gypsy  is  a  descendent  of  Pascal.  It  is  a  unified  programming  and 
specification  language  with  facilities  tor  exception  handling,  data 
abstraction,  and  concurrency.  The  specification  component  of  the 
language  contains  the  full  expressive  power  of  the  predicate  calculus 
Specifications  may  bo  written  as  Floyd  Hoare  style  program  annotations, 
algebraic-style  axioms,  or  state  machine  descriptions. 

Gypsy  is  a  procedural  language  but  contains  a  sizable  functional 
component.  The  specification  described  in  this  paper  is  written  entirely 
within  the  functional  subset  ot  the  language.  This  is  typical  tor  abstract 
specifications,  k  Heme  matrons  are  usually  given  in  a  procedural  style. 
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‘’Tire  others  FDM.  which  wilt  not  be  discussed  further  in  this  paper. 


The  following  is  a  fully  specified  Gypsy  implementation  of  a 
factorial  routine  The  entry  and  exit  assertions  in  the  definition  of  f  give 
its  specification  Notice  that  the  function  f«ct  is  a  specification  function 
against  which  the  code  is  veritied. 

scope  factorial_exaaple  ■= 
begin 

function  F  (n:  integer) :  integer  = 
begin 

entry  N  ge  0; 

exit  result  a  fact  (N) ; 

var  i:  integer  :=  1; 

result  : =  1  ; 

loop 

result  :*  result  *  i; 
if  i  =  n 

then  leave 
else  i  :=  i  +  1 
end  (if) 
end  { loop) 
end;  (function  F) 

function  fact  (n:  integer) :  integer  = 
begin 

«,xit  result  = 

if  n  la  0 
then  1 

else  n  *  fact  (n-1) 
fi, 

end;  (function  fact) 
end;  (scope) 

Gypsy  is  fully  described  in’  and  a  methodology  (or  using  the  language 
effectively  is  documented  in2 

The  Boyer-Moore  Logic 

The  Boyer-Moore  logic  is  a  quantifier-tree  constructive  first-order 
logic  with  equality  and  rules  for  defining  recursive  functions.  The 
language  is  a  minor  variant  ot  Pure  Lisp'8  and  consists  of  variables  and 
function  names  combined  in  a  prefix  notation  Predicates  are 
represented  as  boolean  valued  (unctions.  Though  untyped,  the  logic 
supports  a  restricted  version  ot  usor-detined  recursive  dala  types  (the 
"shell  principle")  Despite  the  absence  ot  quantifiers  in  the  logic,  the 
system  allows  one  lo  prove  lemmas  that  are,  in  effect,  treated  as 
universally  quantified  statements. 

A  Boyer-Moore  specification  ot  the  factorial  function  has  tho  form 
Definition 

(ZEROP  N) 

(OR  (EQUAL  N  0) 

(NOT  (HUKDERP  N) ) ) 

Definition 
(FACTORIAL  N) 

(IF  (ZEROP  N) 

1 

(TIMES  N  (FACTORIAL  (SUB1  N)  )  )  )  . 
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The  Boycr-Moore  definition  principle  guarantees  tnat  functions  accepted 
by  the  Boyer-Moore  system  are  total.  Thus,  (facto rim.  n)  is  defined 
even  if  K  is  no!  a  numeric  argument.  This  contributes  to  a  specilication 
style  which  is  quite  different  than  that  used  in  Gypsy.  The  logic  is  fully 
desenbod  in'9’". 

The  Main  Differences 

The  primary  differences  in  the  two  languages  are  summarized 
below. 

1 .  Syntactically  the  two  languages  are  quite  different  Gypsy  syntax 
Is  Pascal-like  mixed  infix/prefix  notation;  the  Boyer-Moore  logic 
uses  a  LISP-Irko  prefix  syntax. 

Z.  Gypsy  provides  procedures,  including  concurrent  procedures.  The 
Boyer-Moore  logic  is  purely  functional. 

3.  Because  of  the  procedural  aspects  of  the  language,  the  semantics 
ot  Gypsy2'  is  significantly  more  complex  than  that  of  the  Boyer- 
Moore  logic.  The  Boyer-Moore  logic  has  a  simple  applicative 
semantics,  in  a  certain  sense,  an  interpreter  for  the  logic  can  be 
delined  fairly  easily  within  the  logic. 

4.  Gypsy  encourages  a  top-down  development  style  by  allowing  the 
programmer  fo  leave  implementations  pending  This  permits 
references  to  and  proofs  about  routines  which  are  not  fully 
elaborated.  In  the  proof  domain,  there  is  no  enforced  constraint 
that  lemmas  be  proved  beforo  they  are  used.  The  Boyer-Moore 
logic  encourages  a  bottom  up  development  style  since  functions 
must  be  accepted  before  they  can  be  referenced  Top-down 
development  o(  proofs  can  bo  accomplished  in  the  Boyer-Moore 
framework  by  adding  lemmas  as  axioms  and  Ihen  later  redoing  the 
proof.  However,  this  is  counter  to  the  paradigm  ol  proof 
development  in  the  Boyer-Moore  system;  it  is  assumed  that 
lammas  will  be  proved  belore  they  are  used. 

5.  Gypsy  data  typing  restricts  syntactically  the  passing  of  arguments 
to  routines.  However,  there  is  at  present  no  guarantee  that 
routines  will  be  defined  even  for  arguments  of  permissible  type 
The  Gypsy  Verilicatscn  Environment  supports  partial  correctness 
prools;  that  is.  proofs  ol  termination  must  be  pertormeo  outside  th< 
system.  The  Boyer-Moore  definition  principle  guarantees  that  all 
functions  are  total.  Arguments  which  are  not  o!  the  expected  type 
are  usually  treated  as  H  they  were.  Thus  the  Boyer-Moore  function 
factorial  above  treats  a  non  numeric  argument  as  T  it  were 
zero. 

6  The  Gypsy  specification  language  contains  the  universal  and 
existential  quantifiers.  The  Boyer-Moore  logic  is  constructive  and 
quantifier  free.  Lemmas  involving  variables  are  regarded  as 
implicitly  universally  quantified  To  obtain  the  effect  of  an 
existential  quantilier  H  is  necessary  to  provide  a  "witness  function" 
which  computes  the  required  value. 

THE  LOW  WATER  MARK  PROBLEM 

The  Low  Water  Mark  problem  was  mtroduced  in14  and  used  there 
tor  a  comparison  ot  tour  verilication  systems.  It  was  recently  revived  as 
one  benchmark  problem  for  a  more  extensive  comparison  ot  verification 
systems  reported  in15.  In  the  context  ot  that  study,  two  distinct  solutions 
to  the  problem  were  coded  in  Gypsy’6' 1 1 .  We  describe  a  third  solution, 
coded  in  Gypsy  and  In  the  Boyer  Moore  logic  and  fully  verified  in  each  ol 
the  two  systems.  The  method  ot  specilication  follows  the 
non  interference  approach  described  in  the  following  section. 

Cheheyl.  etal  describe  the  Low  Water  Mark  problem  as  follows: 

The  example  system  has  at  least  one  data  object  and  three  operations: 
READ,  WRITE,  and  RESET  The  operations  are  usod  by  several 
processes  having  various  fixed  security  levels.  The  system  is  required 
to  satisfy  the  simple  security  and  *  property.  For  simplicity  the  security 
levels  are  assumed  to  be  lineariy  ordered. 

...The  low  water  mark  idea  is  that  the  data  object  has  a  security  level 
that  can  decrease  but  not  increase  except  via  RESET.  A  decrease  in 
level  occurs  when  the  object  is  (totally)  rewii’ten  by  a  lowor  level 
process.  The  new  level  ol  ihe  object  is  the  level  ot  the  calling  process. 

Tho  Bell  and  LaPadula  simple  security  and  ‘-properties22  are  following 
requirements;  for  a  process  to  read  an  object  the  process  level  must 
dominate  that  ol  tha  object;  to  write,  the  object  level  must  dominate  tha! 


ol  tho  process.  A  read  involves  no  change  ol  levels  lor  the  object;  a 
write  causes  tho  object  level  to  drop  to  that  ol  the  process.  Reset 
causes  the  object  security  level  to  become  system  high  and  tho  value  ol 
tho  object  to  become  undefined. 

Cheheyl,  et  at.  require  that  the  dominates  relation  on  levels  be  a 
total  ordering  lor  simplicity."  However,  Rushby23  has  shown  that  tho 
system  described  is  insecure  it  the  levels  are  only  partially  oidered. 

NON-INTERFERENCE 

The  security  model  for  our  solution  to  the  low  waler  mark  problem 
is  a  non-interterence  model.  Thu  notion  ol  non-interference  assertions 
was  developed  by  Goguen  and  Meseguer24- 25  and  elaborated  upon  by 
Rushby26.  It  provides  a  powerful  and  quite  general  mechanism  tor 
describing  security  policies.  Non-interference  has  been  applied 
successfully  in  tho  proof  ot  certain  security  properties  of  the  Honeywel1 
Secure  Ada  Target  machine27. 

Process  p,  is  said  to  be  non-interfering  with  process  p?  (denoted 
p,  )->  p£  if  no  instruction  issued  by  p,  can  influence  the  future  output  of 
the  system  to  p2  A  non-interference  security  policy  is  simply  a  set  ot 
assertions  which  characterize  which  interferences  between  processes  in 
a  system  are  prohibited  (alternat'vely  a  binary  relation  on  processs).  This 
notion  can  be  rendered  more  amenable  to  formal  treatment  by  the 
following  observation:  tor  any  sequence  ot  operations  seq. 

p,  W  p2  b  Viewp  (seq)  *.  Viewpj(seq/p,) 

where  Viewp(seq)  is  ihe  complete  picture  that  process  p  has  ot  the  stale 
of  the  system,  and  seq/p  is  the  subsequence  ot  seq  obtained  by  deleting 
those  instructions  executed  by  p. 

Our  non  interference  policy  is  a  simplification  nt  the  DoD  MLS 
policy.  Processes  have  associated  levels  which  are  related  by  a  total 
order.  Process  p,  may  interfere  with  process  p2  only  H 
leveljp,)  <  levelfpz).  That  is.  the  security  policy  is  characterized  by  the 
following  set  ot  non-interference  assertions: 

{p,  \  >p2  :  -•  Ievel(p,)  <  'evel(p2)j. 

We  notice  that  it  is  only  tho  levels  of  individual  processes  that  are 
relevant  to  security.  Consequently,  to  demonstrate  that  security  is 
maintained  in  tho  system  it  suffices  to  show,  for  an  arbitrary  process  p. 
that  no  instruction  executed  on  behalf  ot  any  process  at  a  Higher  level 
can  affect  p’s  view.  That  is, 

Viowp(5eq)  =  Viewp(seq/level(p)), 

where  seqAovel(p)  is  the  instruction  sequence  purged  ol  all  instructions 
executed  on  behalf  ot  processes  at  levels  not  dominated  by  level(p)  It  is 
proved  in27  that  this  policy  implies  both  simple  security  and  the 
properly.  Thus,  it  satisbes  the  constraints  ot  the  low  water  mark 
problem. 

THE  SPECIFICATIONS 

In  this  section  we  give  the  Gypsy  and  Boyer-Moore  specilications 
of  tha  non-interference  policy  described  in  Ihe  preceding  paragraph  For 
readabiiily  we  write  all  Gypsy  code  in  lower  case  and  all  Boyer-Moore 
code  in  upper  case  Enough  elaboration  is  given  here  (we  hope)  to  give 
a  clear  idea  of  the  nature  and  details  ol  each  of  the  two  specifications 
The  reader  interested  in  the  complete  set  ot  definitions  and  lemmas  is 
referred  to28.  Tho  Gypsy  version  is  described  in  detail  in29. 

The  Main  Data  Types 

The  notions  (data  types)  ot  process,  object,  state,  and  instruction 
appear  in  each  specilication  To  avoid  entanglement  in  syntactic  details, 
we  give  only  an  outline  ot  the  main  data  types  here,  namely  stale,  level, 
and  instruction  sequence  (and  relevant  auxiliary  types)  Wo  refer  tho 
reader  to20  il  more  details  are  desired. 

Security  States.  Let  us  begin  with  Gypsy  In  the  Gypsy  spec,  an 
object  is  arbitrary;  the  object  type  is  declared  lo  be  pending  Similarly, 
tho  process  type  is  pc  tiding  However,  the  types  object_lgvet_map. 
object_valuo_map,  and  process_va!ues_map  are  declared  in  order  to 
specify  a  security  state  with  the  following  (Pascal-like)  type  declaration: 
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type  secui:ity_state  “ 

record  (values_read:  proceas_valuas_map; 

ohjact_lEval :  object_l*vol_jnap; 
ob J a c t. _ v a  1  ua :  ob  ject_valuo_jnap) ; 

The  three  types  referred  to  in  tnis  record  are  declared  as  mappings,  for 
example,  one  such  dcclaralion  is 

type  proc«S8_v»lu0s_map  = 

mapping  from  process  to  value_aaquence; 

where  one  declares 

type  Tslue__flQquenca  «  flQ-juenca  of  v*lua__type; 

Thus,  the  values  road  by  process  p  are  obtained  by  taking  the 
valuea_r<i«d  component  of  the  state  and  then  applying  the  resulting 
mapping  to  the  process  p: 

state.  valuas_read[p] 

The  Boyer-Mooro  type  declarations  are  quite  similar,  except  that 
there  are  no  "mapping  types".  Let  us  begin  with  processes.  Thus,  for 
example,  the  values  read  by  a  process  are  a  component  o(  the  process 
rather  than  the  result  ot  applying  a  (unction  to  the  process.  The  following 
syntax  is  simply  a  declaration  of  a  process  as  a  record  type  with  two 
fields.  Thus  if  (processp  x)  is  true,  then  (proc-name  x)  equals  the 
value  of  the  first  field  and  (values -read  x)  equals  me  valt.j  of  the 
second  field.  Conversely,  it  ProcName  and  ValRaad  are  these  two 
respective  values,  then  x  -  (process  Prociia-me  vaiRaad) ,  .  e. 
process  is  actually  a  (unction  which  constructs  a  process  from  a  name 
and  some  values-read. 

Shell  Definition 

Add  the  ohell  PROCESS  of  two  arguments 

with  recognizer  PROCESSP 

and  accessors  PROC-NAME  and  VALUES-READ 

(Remark  for  readers  familiar  with  the  Boyer-Moore  logic.  The  reader 
may  notice  that  we  have  omitted  declarations  ot  the  type  restrictions, 
default  values,  and  bottom  object  from  the  following  shell  definition  in 
fact  these  are  none.  Zero,  and  none,  respectively.  Similar 
simplifications  will  bo  made  in  the  other  shell  definitions  presented 
below.) 

in  the  Boyer-Moore  specification,  it  was  convenient  to  choose  to  access 
the  values-read  as  a  (unction  ol  the  name  of  a  proci  ss  rather  than  of  the 
process  itself  An  advantago  to  this  approach  is  that  it  is  absolutely  clear 
that  the  lovel  of  a  process  does  not  change  during  the  execution  ot 
instructions,  however,  this  is  also  a  disadvantage  since  Itio  model  is  less 
general  At  any  rate,  in  the  Boyer  Moore  case,  one  reads  the  values 
from  a  process  name  as  follows: 

(VALUES-READ  (GET-PROCESS  P-NAKE  STATE)  ) 

where  values-read  (defined  above)  is  an  accessor  for  processes  and 
GET-process  is  a  recursively  defined  function: 

(DEFN  CET-PROCESS  (P-HAME  PROCESSES) 

(IF  (NOT  (LISTP  PROCESSES)) 

F 

(IF  (EQUAL  P-HAME 

(PROC-NAME  (CAR  PROCESSES)  )  ) 

(CAR  PROCESSES) 

(GET-PROCESS  P-NAME 

(CDR  PROCESSES)  )  ) )  ) 

Notice  that  this  function  is  necessary  in  the  Boyer-Moore  version 
because  the  Boyer-Moore  iogic  does  not  support  mapping  types.  That 
is,  (unctions  must  be  defined  in  the  logic  rattier  than  being  data  objects 
(such  as  the  object  slalevalues_read  in  Gypsy), 

So,  we  have  defined  the  notion  ol  process  tor  the  Boyer-Moore 
version  The  notion  o!  object  is  similar,  and  we  omit  details: 

Shell  Definition 

Add  tha  shell  OBJECT  of  three  arguments 
with  recognizer  OBJECTP 

and  accesaora  OBJ-NAME.  VALUE,  and  OLEVEL 

We  may  now  define  a  state  to  bo  simply  a  record  consisting  ot  a 
list  ot  processes  and  a  list  ot  objects 


Shell  Definition 

Add  the  ohell  STATE  of  two  arguments 

with  recognizer  STATE? 

and  accessors  PROCESSES  and  OBJECTS 

Actually  no  restriction  Is  made  on  the  components  of  a  slate,  because  of 
the  weakness  ol  the  Boyer-Moore  typo  (shell)  mechanism.  Instead,  a 
predicate  troper-statep  is  defined  which  restricts  the  class  ol  "stales" 
torthe  theorem  ultimately  proved  Thus  tho  following  function  (predicate) 
returns  t  (true)  exactly  when  Its  argument  is  a  siale  whose  component 
are  respectivly  a  list  of  processes  and  a  list  of  stales  (Thus  the 
functions  process-i.istp  and  o eject -list?  are  defined  first: 
however,  we  omit  their  straightforward  definitions  here ) 

Definition 

(PROPER -STATEP  STATE) 

(AND  (STATEP  STATE) 

(FROCESS-LISTP  (PROCESSES  STATE) > 

(OBJECT -LISTP  (OBJECTS  STATE) ) ) 

This  kind  of  treatment  of  states  is  necessary  because  the  sequence  of 
type  constructor  of  Gypsy  (used  above  in  tho  declaration  of 
value_sequance )  has  no  real  anatoguo  in  the  Boyer-Moore  logic. 

Level3.  The  notion  of  level  is  spectfied  in  each  language  as  a 
function  (which  is  left  undefined)  However,  as  mentioned  above,  we 
chosa  to  have  the  function  depend  on  the  process  in  the  Gypsy  version 
but  on  the  process  name  in  the  Boyer-Moore  version. 

function  process_level  (p:  process) : 

level_type  “  ponding; 

Declaration 

(plevel  proc-name)  »  [unspecified] 

There  is  one  other  ditlerence  in  the  handling  ol  levels  by  the  two 
versions  The  Gypsy  version  (which  was  done  first)  used  the  integer 
ordering  functions  in  oiuui  iu  order  iiie  levels.  thus  treating  ieral_type 
(seo  above)  as  though  it  were  the  type  ol  integers  This  had  the 
advantage  of  allowing  tho  Gypsy  simplifier  to  contribute  its  built-in 
knowledge  ot  integers  (and  their  ordering)  to  the  proof  However,  the 
Boyer-Moore  version  was  undertaken  with  tho  goal  ot  allowing  an 
arbitrary  total  order,  dominates,  with  the  axioms  tor  a  total  order 
included.  This  was  indeed  accomplished,  and  no  other  axioms  were 
needed  except  that  the  'system  high"  level  is  ihe  greatest  level 
(dominates  (system-high)  L) .  (A  similar  axiom  was  added  for  tho 
Gypsy  proof  as  well.) 

Instruction  Sequences  The  notion  ot  instruction  is  defined  as  a 
record  in  each  language,  with  fields  corresponding  roughly  to  the  type 
(i.e.  read,  write,  or  reset),  process,  object,  and  value.  (Ol  course,  the 
value  lield  is  not  necessary  tor  a  read  instruction:  it  is  simply  ignored.) 

type  inatruction_claa»  ■  (rd,  wrt,  rst) ; 

type  instzuction  *« 

record  (class:  instruction_class; 
p:  process; 
o:  object; 
v :  value_type) 

Shell  Definition 

Add  the  shell  MAKE-INSTRUCTION  of  four  arguments 
with  recognizer  INSTRUCTION 
and  accessors  TYPE,  I-PROC-NAME, 

I -OBJ-HAMF.,  and  I -VALUE 

The  notion  ot  instmclion  sequence  is  declared  as  a  type  in  Gypsy 
but  is  defined  by  a  recursive  function  in  the  Boyer-Moore  logic  (again, 
because  there  is  no  sequence  type  constructor  in  that  logic): 

type  instruct ionsequence  *= 
sequence  of  instruction; 

Definition 

(INSTRUCTION -LISTP  LST) 

* 

(IF  (NOT  (LISTP  LST)) 

T 

(AND  (INSTRUCTION  (CAR  LST)  ) 

(INSTRUCTION -LISTP  (CDR  LST) ) ) ) 
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Definition 

(WRITE  LEVEL  0  V  ST) 

(IF  (DOMINATES  (OLEVEL  O)  LEVEL) 

(STATE  (PROCESSES  ST) 

(REWRITE-OBJECT 
(OBJ-NAME  0) 

V  LEVEL  (OBJECTS  ST) ) ) 

ST) 

whore  (rewriik-object  o-kamb  v  l  objects)  returns  the  result 
of  replacing  the  value  of  the  object  named  o-namb  with  v  and  the  level 
with  L.  in  the  given  list  of  objects.  (We  omit  the  recursive  definition  of 
rewiuts-objkct  .) 

It  remains  to  dofino  purge.  Tho  "values  read"  component  of  the 
now  state  contains,  for  each  process  p,  the  sequence  of  values  recoived 
by  p  as  a  result  of  the  read  instructions  executed  on  its  behalf  In  our 
model,  this  is  the  only  information  that  a  process  can  obtain  about  the 
system.  Thus,  the  following  are  the  definitions  of  purge  Notice  that  tho 
Boyer-Moore  function  is  defined  for  a  much  broader  collection  of 
arguments.  The  typo-free  nature  of  thn  logic  and  tho  requirement  that  all 
functions  be  total  requires  that  purge  be  defined  on  arguments  whicti 
are  intuitively  quite  different  than  the  intended  "argument  types  ' 

function  purge 

(inseq:  in8truction_aequence; 

1:  level_type)  :  instruction_oequGiica  = 

begin 

exit,  result  « 

if  inseq  =  null  (lnatruction_sequence) 
then  null  (instruction_sequence) 
else  if  1  ge 

process_level  (last  (inseq) .p) 
then  purge  (nonlast  (inseq) ,  1) 

<:  last  (inseq) 

else  purge  (nonlast  (inseq) ,  1) 
fi 

fi; 

end;  (purge) 

Definition 

(PURGE  INSTLIST  LEVEL) 

s 

(IF  (NOT  (LISTP  INSTLIST)) 

INSTLIST 
(IF  (DOMINATES 
LEVEL 
(F  LEVEL 

(I-PROC-NAME  (CAR  INSTLIST)  ))  ) 

(CONS  (CAR  INSTLIST) 

(PURGE  (CDR  INSTLIST)  LEVEL) ) 

(PURGE  (CDR  INSTLIST)  LEVEL)  )  ) 

OUTLINES  OF  THE  PROOFS 

The  main  lemmas  for  the  proofs  are  similar.  In  each  case,  tho 
idea  is  to  proceed  by  some  kind  of  induction  on  tho  lengtn  of  the 
instruction  list  However,  in  order  to  obtain  a  sufficiently  strong  inductive 
hypothesis  it  is  desirable  to  prove  a  somewhat  stronger  result  than  the 
main  theorem  (which  was  called  "System  Is  Secure"  above),  from  which 
the  main  theoiem  follows  Immediately  The  stronger  result  says  that  the 
given  process  has  tho  same  view  ot  the  two  relevant  states,  namely  tho 
ones  obtained  with  and  without  running  the  purged  instructions. 

function  process_view_identic«l 

(p:  process; 

statel,  state2:  aecurity_Btate) 

:  boolean  “ 

begin 

exit  result  = 

(  statel . values_read[pi  m 
state2 .  values_  read  [p] 
t  (all  ol:  object, 

ol  in  could_read  (p,  statel) 
iff  ol  in  could_read  (p,  state2)) 
t  (all  o2 ■  object, 

o2  in  could_read  (p,  statel) 

->  statel .object_level[o2) 

■  state2 .object  level [o2] 


A  statel  object_value(o2] 

=  stste2 ,ob ject_value[o2) ) ) ; 
end;  (proca»B_»i«»  identical) 

whero  tho  (unction  could_read  returns  the  sot  ol  objects  that  can  bo 
read  by  the  given  process: 

function  could_read 
(p;  process; 

state:  securit.y_atate)  :  object_set  =* 
l>egin 

exit  (all  o:  object, 

o  in  lcault. 

iff  proceaa_level  (p)  ge 

atate . ob ject_level [o] ) ; 
end;  (could_read) 

lenxua  purge_preservea_pEoeeaa_view 
(inseq:  inst  ruction_aequence; 
state:  secuvity_state; 
p:  process)  » 
procoss_view_identical 

(p,  interpret  (inseq,  state), 
interpret 

(purge  (inseq,  process_level  (p) ) , 
state) ) ; 

And  now  the  Boyer-Moore  version: 

Definition 

(PROCESS -VIEW- IDENTICAL  P-NAMK  ST1  ST2) 

(AND  (EQUAL 

(GET-PROCESS  P— NAME  (PROCBSSF.S  ST1)  ) 
(GET-PROCESS  P-NAMK  (PROCESSES  ST2)  )  ) 
(OBJECT-NAMES -AGREE  (OBJECTS  ST1) 

(OBJECTS  ST2) ) 

(OBJECTS  -MATCK-BELOW-LEVEL 
(rlieTvEu  r-KArSE) 

(OBJECTS  ST1 ) 

(OBJECTS  ST2) ) ) 

where  object  -names  -agree  returns  t  (tmo)  when  tho  two  object  lists 
have  the  same  names  (in  the  same  order)  and 
OBJEcts-hatch-bklow-levkl  implies  that  the  given  object  lists 
agree  when  restricted  to  objects  below  the  given  lovol: 

Definition 

(OBJECTS -MATCH 'BELOW -LEVEL  LEVEL  0BJS1  0BJS2) 

(IF  (AND  (LISTP  OBJS1)  (LISTP  0BJS2)) 

(IF  (OR  (DOMINATES  LEVEL 

(OLKVKL  (CAR  OBJSX)  )  ) 
(DOMINATES  LEVEL 

(OLKVKL  (CAR  0BJS2)  )  )  ) 

(AND  (EQUAL  (CAR  OBJS1)  (CAR  OBJS2)  ) 
(OBJECTS-MATCH-BRLOW-LKVKL 

level  (cdr  or  :si)  (cdrobjs2))) 

(OBJECTS -MATCH -BELOW  -LEVEL 

LEVEL  (CDR  OBJS1)  (CDR  OBJS2)  )  ) 

(AND  (NOT  (LISTP  0BJS1)) 

(NOT  (1ISTP  0BJS2)  )  )  ) 

Thus  we  are  brought  to  tho  Boyer-Moore  version  ot  the  main  lemma. 

Lemme  (PURGE-PRESERVES  PROCESS-VIEW) . 

(IMPLIES 

(AND  (PROPER-STATEP  ST) 

(INSVRUCTIOM-LISTP  INSTLIST) ) 

(PROCESS -VIEW -IDENTICAL 
P-NAMK 

(INTERPRET  INSTLIST  ST) 

(INTERPRET  (PURGE  INSTLIST 

(P LEVEL  P-NAMK)  ) 

ST))) 


In  both  versions,  there  are  two  main  sublemmas  used  for  proving 
the  inductive  step  ol  this  lomma,  i.e.  tor  proving  (roughly)  that  tho  lemma 
remains  true  when  one  considers  one  more  instruction  on  the  given  list 
of  instructions,  l'ho  first  lemma  treats  tho  case  that  the  added  instruction 
has  a  level  which  is  higher  than  ttiat  of  the  given  process  (and  may 
therelore  be  purged): 
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Tho  Main  Theorem 

Following  the  simple  security  and  ‘-properties  mentioned  earlier, 
wo  imagine  executing  instructions  which  request  roads,  writes,  and 
resets,  whoro  ‘illegal*  requests  aro  ignored.  Thus  a  process  may  not 
read  an  object  at  a  strictly  higlmr  level  or  wrilo-to  (or  reset)  an  object  at  a 
strictly  lowor  level  Let  us  begin  by  staling  tho  main  security  theorem  in 
each  of  tho  two  languages.  We  will  then  give  delinilions  of  functions 
used  in  those  statements,  including  interpret,  which  runs  the  given 
instruction  sequence  on  tho  given  state  (to  return  a  new  state),  and 
purgo,  which  lemovos  all  instructions  whoso  level  exceeds  the  level  ol 
tho  given  process  In  tho  Gypsy  version,  one  considers  the  equality  of 
tho  values  read  by  a  given  process  in  tho  lollowing  two  states:  tho  state 
obtained  alter  nmning  the  original  instructions  and  the  state  obtained 
attor  nmning  tho  purged  instructions.  In  the  Boyer  Moore  version,  we 
have  chosen  to  consider  these  two  processes  rattier  than  just  the  values 
that  they  havu  read,  since  a  process  is  merely  a  name  together  with 
those  values  Either  way,  the  definitions  ol  tho  purge  lunction  guarantee 
security  of  the  system  because  the  purged  instructions  have  no  effect  on 
the  process's  view  of  the  system. 

lamna  sy»tam_l»_»ecure 

(inseq:  inotruction_sequence; 
state. :  security_atata; 
p:  process)  “ 

[interpret  (inseq,  stato)  . valu«a_read[pj  =■ 
interpret  (purge  (inseq,  process^level  (p) )  , 
state) . values_raud[p]  j  ; 

Lemma  (SYSTEM  IS  SCCURt) 

(IMPLIES 

(AND  (PROPER-STATEP  ST) 

(INSTRUCTION-LISTp  INSTLIST)  ) 

(EQUAL  (GET-PROCESS 
P-NAME 

(PROCESSES  (INTERPRET  INSTLIST  ST))) 
(GET-PROCESS 
P-NAME 
(PROCESSES 

(INTERPRET  (PURGE  INSTLIST 

(PLEVEL  P-NAME)  ) 

ST))))) 

The  function  interpret  takos  a  sequence  ol  instructions  and  an 
initial  state  and  returns  a  new  stale  It  is  in  turn  defined  in  terms  ot  a 
"single  stepper"  which  interprets  a  single  instruction  Notice  that  the 
Gypsy  definition  of  interpret  recursively  decomposes  Iho  instruction 
sequence  from  the  right  while  the  Boyer-Moore  definition  works  from  tho 
left  Gypsy  syntax  supports  accessing  sequences  from  either  end. 
Boyer-Moore 's  LISP  like  stylo  strongly  favors  recursively  decomposing 
lists  from  the  left.  1  he  Boyer  Moore  version  of  interpret  "runs"  tho  given 
instructions  in  the  reverse  of  Iho  order  in  which  the  Gypsy  version  "runs" 
the  instructions. 

function  single_atap  (i:  instruction; 

atate:  security_state) 

: security^state  ■ 

begin 

exit  reault  = 
if  i. class  *  rd 

then  read  (i.p,  i.o,  state) 
else 

if  i. cl  ass  —  wrt 

then  write  (i.p,  i-o,  i.v,  „tate) 
else  reset  (i.p,  i.o,  state) 
fi 

fi; 

pending 

end; 


function  interpret 

(inseq:  instruct ion_sequence; 
atate:  security^ state) :  security_state  = 

begin 

exit  result  «* 

if  inseq  *=  null  (instruction_aequence) 
then  atate 
else  slngAO_step 

(last  (Inseq), 

interpret  (nonlast  (inseq), 
state) ) 
fi; 

pending 

end; 


Definition 

(SINGLE-STEP  INST  ST) 

(IF  (GET-OBJECT  ( I -OBJ -NAME  INST) 

(OBJECTS  ST) ) 

(IF  (EQUAL  (T1TE  INST)  'READ) 

(READ  ( I -PROC-NAKE  INST) 

(I -OBJ  INST  ST)  ST) 

(IF  {EQUAL  (TYPE  INST)  'WRITE) 

{WRITE  (PLEVEL  (I-PROC-NAME  INST)) 
(I-CBJ  INST  ST) 

(I -VALUE  INST) 

ST) 

(RESET  (PLEVEL  (I-PROC-NAME  INST)) 

(I -OBJ  INST  ST)  ST))) 

ST) 

Definition 

(INTERPRET  INSTLIST  ST) 

(IF  (NOT  (L1STP  INSTLIST)) 

ST 

(CAR  INSTLIST) 

(INTERPRET  (CDR  INSTLIST)  ST))) 

flic  auxiliary  read,  write,  and  reset  functions  lake  a  sccuiity  state 
together  wilh  other  appropriate  arguments  (such  as  process  or  its  level, 
object,  and  value),  and  return  a  new  stale  However,  tlm  state  is 
unchanged  if  tne  relevant  levels  aio  inappropriate  For  example,  here 
are  the  two  definitions  ot  write .  Notice  that  the  Gypsy  syntax  is  richer  in 
that  its  with  construct  allows  a  convenient  notation  tor  updating 
specified  fields  ot  a  record 

function  write  (p:  process;  o:  object; 

v:  value_type; 
atate:  security  atate) 

:  aecurity_atate  * 
begin 

exit  reault  = 

if  proceaa_level  ip)  le 

state . object_level [o] 
then  atate 

with  ( . ob ject^value [o]  :=  v; 

. ob;)ect_level [o]  := 

procesa_level  (p) ) 

else  atate 
fi; 

pending 

end;  (Krite) 

Recall  below  that  processes  picks  out  Iho  processes  field  of 
the  given  state,  and  similarly  for  objects. 


lama 

purooiblt_  1  ngtr-uctlon  pimma  procaaa 
(a:  iuntructlon; 
p:  pxocass; 

atatal,  atat«2 ;  »acurity_ state)  — 
not  pioc«ea_lemel  (a.p)  la 
procasa_lavaX  (p) 

4  pi'OCsiis^TUir^idaaUnal 

(p,  atatal,  atato2) 

->  procass_ viewidentical 

(p.  aingle_atep  (a,  atatcl),  atate2) ; 

Lemma 

(PURGEABLC  INSTR  PRESERVES PROCESS  VIEW). 

(IMPLIES 

(AND  (PROPER-STATWP  ST1> 

(FROPER-STATEP  ST2) 

( INSTRUCTION!'  INST) 

(PROCESS -VIEW-IDENTICAL  P-NAKE  ST1  ST2) 

(NOT  (DOMINATES 

(PLEVEL  P-NANE) 

(PUiVKL  (I-PROC-NANK  INST))))) 

(PROCESS -VIEW-IDENTICAL 
P-HAKE 

(SINGLE-STEP  INST  ST1) 

ST2)) 

The  other  lemma  treats  tho  other  case,  i.e.  whore  the  added  instruction 
is  not  purged: 

lentil* 

nonpurgaabla  alngla  step  preserves  process  view 
(p :  procaaa ; 
a;  inatructlon; 

atatal,  atata2:  aecurity_state)  = 
proceaa^leval  (a.p)  le  proceaa_level  (p) 

4  procoss_vi« w_identic»l  (p,  atatal,  atata2) 

->  proceaaview^ldontlcal 

(p,  alngla_atep  (a,  atatal) , 
aingle__atop  (a,  atate2)); 

Lemma 

(NONPURG  EABL  E-INS  IRUC 7 ION  PRE  SERVLS 
PROCESS  VIEW) 

(IMPLIES 

(AND  (PROPKR-STATEP  ST1) 

(PROPKR-STATEP  ST2) 

(PROCESS-VIEW-IDENTICAL  P-NANE  ST1  ST2) 
(DOMINATES 

(PIEVEL  P-NAME) 

(PLEVEL  (I-PROC-NAMK  INST)))) 

(  PROCESS -VT  EW- IDENTICAL 
P-NAME 

(SINGLE-STEP  INST  PT1) 

(SINGLE-STEP  INST  ST2) ) } 

Both  proofs  use  a  number  ol  additional  subsidiary  definitions  and 
lemmas.  However,  tho  Boyer  Moore  system  certainly  provides  a  much 
more  powerful  level  ol  automatic  support. 

COMPARING  THE  TWO  METHODOLOGIES 

We  compare  the  following  aspects  ol  the  Gypsy  and  Boyer-Moore 
methodologies: 

•  S pacification  style 

•  Proof  management 

•  Style  oi  interaction  with  the  prover 

•  Soundness 

Specification  Style 

Gypsy  is  a  rich  language  in  that  it  has  sols  and  functions  as  first 
class  data  objects,  first-order  quantifiers,  and  an  expressive  typing 
discipline  for  usor-defined  ypes  The  Boyer  Moore  logic  does  not  have 
these  features,  but  its  sol',  treatment  of  recursion  and  lists,  along  with  its 
capability  for  introducing  data  types  with  tho  so  called  shell  principle, 
allows  one  suttictent  specitication  power  Gypsy  also  is  richer  in  that  it 
has  procedural  constructs,  though  tor  high  level  specs  (such  as  the  Low 
Water  Mark  example)  users  of  Gypsy  have  found  it  advantageous  to  use 
a  functional  style.  In  spite  ot  the  difterem  notions  ot  data  type  and  the 


groator  oxprosslve  power  ol  the  Gypsy  language,  tho  specs  arc  clearly 
quito  similar  loi  tho  two  versions  of  tho  Low  Wator  Mark  oxamplo  that  arc 
presented  here. 

Tho  issue  ot  typos  doserves  furthor  commont  Considor  tho 
following  (incorrect)  statement  ot  tho  main  theorem  in  the  Boyer  Moore 
logic.  Sadly,  an  earlier  version  ol  our  specitication  contoinod  this 
misstatomont.  The  loader  ts  invited  to  find  the  error  before  reading 
furthor. 

Lemma  (SYS1LM  IS  SLCURL). 

(IMPLIES 

(AND  (PROPER-STATEP  ST) 

(INSTRUCTION-LISTP  INSTLIST) ) 

(EQUAL 

(GET-PROCESS  P-NAME 

(INTERPRET  INSTLIST  ST)) 
(GET-PROCESS  P-NAKE 

(INTERPRET 

(PURGE  INSTLIST 

(PLEVEL  P-NAKE)  ) 

ST)))) 

The  problem  with  this  statement  is  that  get-process  is  defined  so  that 
Its  second  argument  is  (expected  to  be)  a  list  ol  processes,  not  a  state 
In  fact,  tho  two  sides  of  the  equality  above  are  actually  both  provably 
equal  to  F  (false),  under  tho  given  hypotheses!  An  analogous  error  in  the 
Gypsy  tex  would  have  boon  caught  by  tho  typo-checker.  However,  the 
problem  ot  matching  formal  specitications  to  intuitive  requirements 
remains  a  central  issuo  in  program  veriticaiion  research 

Proof  Management 

The  Gypsy  system  allows  one  to  dolor  the  proofs  of  lemmas 
during  a  proof  session  This  capability  is  amenable  to  a  top  down  prool 
stylo  which  is  quite  natural.  Tho  Boyer  Moore  system  allows  one  to  add 
axioms,  which  enables  one  to  have  the  same  top  down  capability  to 
some  extent;  one  simply  assumes  seemingly  necessary  lemmas  belore 
proving  the  main  result,  and  then  one  goes  back  and  proves  those 
supporting  tacts.  However,  that  strategy  is  awkward  with  the  Boyer 
Moore  system  since  even:  histones  are  totally  ordered 

Style  of  Interaction  with  tho  Prover 


Tho  Boycr-Moore  prover  is  much  more  powerful  than  is  the  Gypsy 
prover,  and  thus  allows  much  larger  proof  steps  and  is  significantly  less 
tedious  to  operate.  Fven  though  tho  two  verilications  discussed  here 
each  contain  about  thidy  lemmas,  tho  Boyer-Moore  prover  proved  each 
ot  those  lemmas  automatically  (occasionally  with  some  simple  hints 
supplied  with  the  statements  ol  tho  lemmas),  while  tho  Gypsy  prover 
required  considerable  tedious  interaction  in  order  to  prove  many  ot  the 
lemmas.  However,  tho  powedul  heuristics  and  rule-based  rewriting 
capabilities  of  the  Boyer-Moore  provor  also  make  its  behavior  somewhat 
unpredictable  and  also  quite  difficult  and  frustrating  to  control  at  times, 
though  it  prints  out  useful  information  to  help  discover  what  additional 
iemmas  are  needed.  Tho  level  of  interaction  is  not  the  only  significant 
difference  in  the  slyie  ot  interaction  It  is  much  easier  with  the  Boyer 
Moore  system  to  modify  an  existing  proot  and  replay  the  resulting 
definition  and  prool  commands  But  as  mentioned  above,  (tie  Gypsy 
system  is  much  more  flexible  aboul  the  order  in  which  one  gives  proofs 

Soundness 

The  Boyer-Moore  logic,  as  described  completely  in20  and  Chapter 
3  ol’9,  has  simple  and  woll  understood  operational  and  denotational 
semantics  in  which  every  proved  theorem  is  in  lact  true.  Unfortunately, 
the  same  cannot  te  said  ol  Gypsy  Moreover,  tho  Gypsy  system  does 
not  have  a  mechanism  tor  ensuring  that  3ll  lemmas  have  been  proved, 
nor  does  it  guarantee  that  circular  arguments  (in  which  iemmas  use  each 
other  lor  their  precis)  are  not  constructed  Finally,  there  is  empirical 
evidence  over  15  years  for  virtually  bug-free  performance  ot  tho  Boyer- 
Mooro  implementation  that  h3s  not  boon  matched  by  tho  Gypsy 
implementation 

CONCLUSIONS 

Despite  certain  shortcomings,  we  believe  that  tho  Boyer-Moore 
logic  provides  a  reasonable  specification  alternative  lor  secure  systems, 
particularly  at  the  model  levr '  Soundness  of  the  logic  and  the  care  with 


127 


which  It  is  implemented  in  thu  thoorom  provur  aro  strong  advantages  ol 
(ho  Boyer  Mooro  system  over  Gypsy  or  other  currently  available 
verification  systems.  Gypsv,  on  tho  othor  liand,  is  an  uxprossivo  and 
versatile  language  which  provides  tho  bonctits  of  oata  types,  dull 
abstraction,  concurroncy,  conditional  handling,  procedural  semantics, 
etc 

Wo  believe  that  tho  relative  strengths  ol  the  Gypsy  and  Boyer 
Mooro  systems  aro  in  tact  quite  compatible.  Work  is  already  underway 

to  remedy  some  ot  tin  soundness  deficiencies  ot  Gypsy,  ant'  a 
preliminary  Systran  for  tho  Boyer  Mooro  logic  lias  boon  constmcted 
that  uses  tire  Boyer  Mooro  prover  as  a  componont  but  also  allows 
nioru  user  control  Moreover,  a  form  ot  quantification  Iras  already  been 
added  ro  tho  Boyer  Mooro  logic  and  prover"  and  plans  aro  under  way  to 
add  sots,  toll  lirsl  order  quantification,  and  nroto  flexible  sausturing  of 
proofs.  Preliminary  investigation  Iras  also  begun  into  developing  a 
Gypsy  like  syntax  lor  tho  Boyer  Moore  logic-  7  his  "merger"  ot  Gypsy  and 
the  Boyer  Moore  systems  is  the  subject  of  an  active  research  eftort  at 
Computational  Logic,  Inc.,  with  tho  intended  result  to  oo  called  Hose 
7  ho  primary  component  omitted  (rom  Rose  is  expected  to  be  the 
procedural  pad  of  Gypsy  Tho  hope  is  ttiat  technology  will  continue  to  bo 
developed  toward  obtaining  efficient  implementations  ol  functional 
languages,  particularly  with  respect  to  seeming  opportunities  tor 
concurrent  evaluation. 

Out  experiences  to  dale  suggest  that  a  fundamental  requirement 
for  any  successful  verification  is  that  tho  person(s)  doing  the  veriiication 
understand  the  theorems  to  be  proved  A  system  with  Gypsy's  flexibility 
of  language  and  use  and  wiin  the  Boyer  Mooro  system's  proof  power 
and  clear  semantics  would  be  a  great  aid  in  this  respect 
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by  Honeywell.  This  marked  the  beginning  of 
the  current  three  phase  development  described 
below. 

LOCK  is  the  third  phase  of  a  continuing 
project  previously  called  SAT.  The  sat 
project,  begun  in  1982,  was  a  research  effort 
to  design  secure  computers.  Phase  one  (SAT- 
0)  yielded  the  high  level  requirements 
specification  in  1983 . [HONE83 ]  Phase  two 
(SAT-I)  yielded  the  intermediate  design 
specification  in  1988.  [H0NE86]  Phase  three 

(SAT-I I) ,  later  renamed  LOCK,  will  yield  a 
detailed  design  specification  and  a  secure 
microcomputer  prototype  by  1990. 

XI.  TECHNICAL  APPROACH 

The  LOCK  project  goal  is  to 
develop  a  hardware-oriented  solution  to  the 
computer  security  problem  of  providing 
multilevel  security  (MLS )  for  general 
computers.  (MLS  provides  the  ability  to 
process  different  levels  of  classified 
information  so  that  only  properly-cleared 
users  may  access  it.)  The  heart  of  the 
solution  is  the  separate  security-enforcing 
module  called  SIDEARM.  The  S I Df; ARM  will  be 
designed,  built,  and  then  integrated  into  an 
existing  microcomputer.  The  security 

enforcement  will  be  highly  assured  to  allow 
certification  at  the  highest  level  (Al) 
defined  by  the  Department  of  Defense  Trusted 
Computer  System  Evaluation  Criteria . [ TCS E8 5 ] 

A.  Project  Goals 

tcck  is  a  very  ambitious 
information  security  technology  development 
project.  We  wish  to  provide  a  foundation  for 
current  and  future  secure  information 
systems.  This  paper  establishes  the  goals  of 
both  the  base  technology  and  its  extensions 
to  address  a  myriad  of  computer  and 
communications  security  problems.  LOCK 

provides  the  basis  for  the  solutions.  We 
count  on  industry  and  other  projects  to 
extend  and  apply  this  base  to  reap  the  full 
benefit  of  this  technology. 

The  ultimate  goal  is  to 
produce  the  SIDEARM  as  a  standard  product  to 
retrofit  into  most  existing  computer's  and 
included  or  offered  as  an  option  in  new 
computers,  like  a  coprocessor. 

LOCK  strives  to  produce 
very  secure  computers  without  severely 
impacting  performance.  This  work  should  set 
standards  for  a  new  rating,  possibly  A2; 
however,  the  minimum  acceptable  level  v;ill  be 
Al  .  While  meeting  the  requirements  for  at 
least  Al,  the  functionality  of  the  LOCK  is 
desired  to  be  equal  to  that  of  the  unmodified 
base  computer.  Although  this  is  very 

feasible,  certain  security-related 

limitations  may  be  necessary  to  meet  the 
assurance  requirements. 

Preserving  performance  of 
the  machine  is  another  major  concern.  The 
design  team  is  striving  to  achieve  90%  of  the 
speed  of  specified  benchmarks  when  compared 
to  the  unmodified  computer.  The  performance 
area  is  one  that  has  severely  affected 
previous  computer  security  projects.  With 
the  hardware  approach  of  the  security  module, 


the  minimum  acceptable  level  is  80%. 


B.  Reference  Monitor 

The  reference  monitor  model 
(see  Figure  a)  is  inherent  to  the  design  of 
secure  computers.  In  the  model,  the 
reference  monitor  acts  as  a  guard  betwaen 
people  and  information.  There  are  three 
properties  the  reference  monitor  must 
possess.  The  ideal  "guard  at  a  key  desk" 
analogy  best  explains  how  this  model  works. 
The  first  property  is  that  the  reference 
monitor  must  always  be  invoked;  (1)  the  guard 
must  always  be  on  duty,  and  there  must  be  no 
way  to  obtain  a  key  without,  being  confronted 
by  him.  second,  the.  reference  monitor  must 
be  verified  to  operate  correctly;  (2)  the 
guard  must  be  responsible  for  doing  his  job 
correctly.  He  knows  that  one  has  to  have  an 
identification  badge  and  must  be  on  the  key 
access  list.  Finally,  the  reference  monitor 
must  be  tamperproof;  (3)  there  must  be  no  way 
to  hinder  or  affect  the  proper  operation  of 
the  guard.  One  cannot  get  the  guard  confused 
or  substitute  a  guard  of  one's  own  choosing. 


REFERENCE  MONITOR  CONCEPT 


A  REFERENCE  MONITOR  MUST  BE 

1.  ALWAYS  INVOKED 

2.  VERIFIED  CORRECT 

3.  TAMPERPROOF 


C .  Alternative  Solutions 

There  are  essentially  two 
ways  to  implement  the  reference  monitor 
model.  Previously,  the  method  of  choice  was 
to  implement  in  software,  thereby  attacking 
the  computer  security  problem  at  the 
operating  system  level.  This  approach  has 
met  with  four  serious  problems.  LOCK  is  a 
hardware-based  approach  that  attacks  the 
security  problem  at  the  machine  level.  Both 
implementation  methods  are  described  below. 


1 .  Software 

The  traditional 

approach  implements  the  security  kernel  in 
software,  resulting  in  a  poor  instantiation 
of  the  reference  monitor  model.  At  system 
boot-up,  all  of  the  security-relevant 
information,  tables,  etc.,  need  to  be  loaded 
from  memory  into  the  reference  monitor.  To 
do  this,  the  reference  monitor  has  to  be 
bypassed,  thereby  violating  one  of  the 
reference  monitor  properties. 

]  in 
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generic  and  thus  reusable  on  many  different  computers.  Full 
advantage  will  be  taken  of  inexpensive  generic  cryptographic 


modules  currently  in  development. 


X.  HISTORY  AND  SUMMARY 

There  is  an  immediate  need  for  computing 
facilities  to  handle  data  at  different 
security  levels  for  users  possessing 
different  levels  of  clearance.  These 
multilevel  secure  computers  will  fulfill 
three  major  requirements. 

First,  secure  computers  must 
meet  the  need  for  inherently  multilevel 
applications  processing  different  levels  of 
classified  information  and  reporting  to  users 
cleared  to  different  levels.  For  example, 
Military  Air  Command  maintains  flight 
schedule  information.  Most  of  the 
information  is  unclassified  except  for  parts 
having  to  do  with  covert  missions.  The 
intelligence  community's  solution  of  clearing 
everyone  to  the  highest  level  is  impractical 
given  the  number  of  personnel  requiring 
access  to  this  database.  This  problem  will 
only  get  worse  as  the  information  age  forces 
us  to  integrate  more  and  more  information 
processing  systems. 

Second,  enabling  computers  to 
serve  users  with  different,  clearances  avoids 
the  need  to  maintain  duplicate  computers  for 
different  classification  levels.  The 
potential  money  savings  is  significant.  The 
alternative  of  clearing  all  users  to  the 
highest  level  is  too  expensive,  impractical, 
and  unacceptable  from  a  security  standpoint. 


Finally,  secure  computers  are 
extremely  important  even  for  those  systems 
not  requiring  multilevel  applications.  For 
example,  there  is  a  significant  threat  from 
malicious  software  introduced  onto  the  system 
from  a  multitude  of  possible  routes. [MYER80] 
Such  malicious  software  could  destroy 
invaluable  information,  spoof  users  into 
taking  inappropriate  action,  or  prevent 
computers  from  operating  at  critical  times. 

The  need  for  secure  computing 
in  both  defense  and  industry  is  reaching 
critical  proportions  and  will  only  grow.  The 
Logical  Coprocessing  Kernel  ( IX5CK)  project 
promises  to  solve  a  substantial  part  of  this 
problem . 


Current  systems,  and  most  of  those  under 
development,  attempt  to  provide  multilevel 
security  in  software  by  redesigning  the 
operating  system.  The  purely  software 
approach  has  four  serious  disadvantages 
compared  to  the  primarily  hardware  approach 
used  in  LOCK: 

1 .  DECREASED  ASSURANCE 
since  software  malfunction  could  cause  total 
security  failure, 

2 .  DECREASED  PERFORMANCE 
to  usually  unacceptable  levels  because  of  the 
high  overhead  from  the  securitv  access  checks 
done  in  software, 

3 •  LOSS  OF  EXISTING 
APPLICATION  SOFTWARE  because  of  the  extensive 
redesign  of  the  operating  system,  and 

4 .  INABILITY  TO 
FUNCTIONALLY  ENHANCE  the  operating  system 
without  requiring  expensive  and  time- 
consuming  re-verification  and  reevaluation. 

The  LOCK  hardware-oriented  approach 
promises  high  assurance  and  reasonable 
performance  derived  from  the  implementation 
of  a  physically  separate  and  parallel 
security-enforcing  module  called  the  system- 
independent,  domain-enforcing,  assured, 
reference  monitor  (SIDEARM) .  Furthermore, 
because  the  security-related  functionality  is 
in  the  SIDEARM,  the  software  operating  system 
is  not  security-relevant  and,  therefore, 
requires  no  reverification  when  the  operating 
system  software  is  updated.  This  approach 
will  allow  the  preservation  of  most  of  the 
application  software  programs  written  for 
that  operating  system  and  its  subsequent 
releases . 

The  LOCK  program  has  at  least  a 
12-year  history.  The  project  sprung  out  of 
the  Provably  Secure  Operating  System  [NEUM77] 
study,  begun  in  1975  at  the  Stanford  Research 
Institute.  An  implementation  of  the  study's 
recommendations  by  Ford  Aerospace  [ FORDS  1] 
began  in  1980.  The  project  goals  proved  to 
be  too  ambitious  and  the  resources  allocated 
to  reach  those  goals  were  toe  limited.  The 
hardware  part  of  the  Trusted  Computing  Base 
(TCB)  under  this  project  was  continued  under 
the  new  name  Secure  Ada  Target  (SAT)  in  1982 
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Furthermore,  proprietary  data  necessary  to 
integrate  SIDEARM  is  readily  available  since 
it  is  a  Honeywell  machine.  Although  one  of 
the  goals  of  the  LOCK  program  is  to  produce  a 
generic  computer  security  module  that  way  be 
used  on  many  different  machines  with  a 
minimum  of  modification,  the  interface  is 
built  for  a  particular  system  and  requires 
low-level  implementation  detail. 

1.  SIDEARM 

SIDEARM  looks  like  a 
coprocessor  or  I/O  device  (depending  on  how 
it's  retrofitted)  to  the  host  system.  It 
contains  its  own  processor  (actually  between 
one  and  four  MC6S020’s),  its  own  '/ME  bus,  and 
its  own  primary  and  secondary  memory.  More 
processors  were  added  in  an  effort  to  lessen 
the  chance  that  SIDEARM,  with  its  system- 
enforced  access  checks,  will  be  the 
performance  bottleneck  that  has  plagued  other 
computers  with  added  security  functionality. 

Each  of  the  major 
subsystems  in  SIDEARM  has  its  own  processor, 
which  may  be  real  or  virtual.  Virtual 
processors  (VP's)  communicate  by  way  of  a 
message  passing  system.  The  format  is  the 
same  whether  or  not  the  VP  is  on  the  same 
physical  processor.  This  makes  it  easier  tc 
add  more  physical  processors  if  necessary  and 
to  move  VP's  to  different  physical  processors 
for  performance  reasons. 

The  first  major 
subsystem  is  a  front-end  filter  which  screens 
out  illegal  requests  from  the  host.  Since 
this  is  the  only  point  where  the  host  can 
communicate  with  SIDEARM,  this  subsystem  is 
host  specific.  Legal  host  requests  are 
queued  until  they  can  be  serviced.  A 
complementary  vp  allows  SIDEARM  to  access  the 
host's  resources  such  as  host  memory.  These 
requests  are  coordinated  by  a  resource 
manager  (detailed  below) . 

The  main  VP  is  the 
instruction  processor.  Its  job  is  to  take  a 
host-initiated  request,  give  the  appropriate 
part  to  the  other  VP's,  and  execute  the 
corresponding  high-level  algorithm. 

A  resource  manager 
provides  the  other  VP's  with  access  to  system 
resources,  including  host  primary  and 
secondary  memory,  SIDEARM  shared  memory,  host 
devices,  and  host  real-time  clock.  A  media 
manager  is  responsible  for  operations 
affecting  the  Global  Object  Table  (the  data 
structure  that  contains  all  the  security- 
related  information  needed  for  access 
control,  resident  only  in  SIDEARM' s  internal 
memory)  or  SIDEARM  Resident  Objects  (other 
data  objects  used  in  security-relevant 
processing) . 

The  Audit  Processor  has 
its  own  media,  a  laser  disk.  If  this  disk 
becomes  full,  the  operator  will  be  notified, 
and  audit  blocks  will  be  stored  directly  on 
SIDEARM' s  hard  disk.  If  this  last  disk 
becomes  full,  the  system  will  lockup  in  the 
interest  of  security.  This  two-tier  backup  of 
audit  data  is  not  called  out  in  the  Criteria 
but  represents  one  area  of  increased 
assurance  for  LOCK. 


The  last  VP  is  the 
unique  identification  (UID)  generator.  It 

will  produce  a  unique  identifier  that  is 
encrypted.  Encryption  renders  the  UID 

"opaque,"  in  the  sense  that  the  user-visible 
UID  "can  not  then  be  used  to  convey  any 
information. 

SIDEARM,  as  the 

instantiation  of  the  reference  mo  itor ,  is 
responsible  for  checking  access  r  ghts  and 
type  enforcement  controls.  Fin;  access 
rights  are  the  "AND"ed  rights  r--Mn  the 

mandatory  access  controls  (MAC'S) ,  the 

discretionary  access  controls  (DAC's)  and  the 
type  enforcement  controls  [SAYD86] . 


Device  (SEP) 


2  .  SIDEARM _ Encryption 


The  SED  is  a  TEPACHE- 
based  [KIBA86]  cryptographic  module  used  for 
three  purposes  in  LOCK.  First,  it  is  used  to 
encrypt  SIDEARM  media.  This  complements  the 
bulk  encryption  device  (BED)  which  encrypts 
the  host's  secondary  memory. 


Second,  the  SED 
encrypts  the  UID  attribute  of  objects  to 
close  a  covert  channel .  This  covert  channel 
rested  on  a  subject's  ability  to  determine 
how  many  objects  had  been  created.  By  one 
subject  creating  either  a  large  or  a  small 
number  of  objects,  another  subject  could 
monitor  that  number  by  creating  an  object  of 
its  own  and  looking  at  the  UID  (assuming 
UIR's  are  monotonically  increasing)  and 
decode  information  over  time.  By  encrypting 
the  UID's,  a  subject  cannot  determine  the 
absolute  or  relative  number  of  objects 
created. 

Third,  the  SED  is  used 
to  manage  the  cryptographic  keys  for  the  BED. 
The  System  Security  Officer  will  insert  his 
crypto-ignition  key  (CIK)  into  this  module  to 
turn  on  the  LOCK.  When  the  CIK  is  inserted 
(during  normal  operation),  the  host's  primary 
memory  has  unencrypted  information  that  is 
potential] y  sensitive  (classified).  When  the 
CIK  is  removed,  all  memory  is  nonsensitive 
(primary  has  no  information  and  secondary  is 
encrypted)  and  can  be  treated  as  any  other 
high-value  piece  of  office  equipment. 
Cryptographic  keys  will,  themselves,  be 
encrypted  withir.  the  encryption  devices  and 
stored  on  SIDEARM 's  secondary  memory.  The 
owning  cryptographic  module  will  retrieve, 
decrypt,  use,  and  then  reencrypt  keys 
whenever  required  by  the  SED  or  the  BED. 
Neither  the  host  system  nor  SIDEARM 
(exclusive  of  the  SED)  will  ever  access  or 
store  unencrypted  keys. 


At  some  future  time, 
the  SED  nay  be  used  as  part  of  a  trusted  path 
between  the  TCB  and  the  user's  terminal. 
Information  could  be  encrypted  at  the 
terminal  and  sent  to  SIDEARM.  Since  only 
SIDEARM  would  be  able  to  decrypt  and  the 
user's  terminal  encryption  device  able  to 
encrypt  it,  untrusted  software  would  not  be 
able  to  generate  or  observe  this  information. 


(BED) 


3 .  Bulk  Encryption  Device 
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The  bulk  encryptor  also 
contains  the  TEPACHE  which  is  used  to  encrypt 
all  data  stored  on  the  host  system  disks, 
tapes,  and  floppy  disks-  Furthermore,  it 
will  be  used  to  encrypt  communications  on  the 
network  interface  port.  All  of  the 
nonprimary  memory  devices  and  the 
communications  port  are  located  on  their  own 
bus,  separated  from  the  CPU/mam 
memory/SIDEARM  bus  by  the  bulk  encryptor  (see 
Figure  f)  .  Secondary  memory  may  be  treated 
as  nonsensitive  (unclassified)  and  no  longer 
must  be  physically  secured  when  unattended. 


Turning  secondary 
memory  nonsensitive  (unclassified)  has 
another  important  result.  Previously,  the 
device  controllers  either  had  to  be  verified, 
trusted,  or  front-ended  with  antilistening 
logic  to  prevent  the  reception  of  unencrypted 
information  not  intended  for  that  particular 
device.  Now  this,  too,  is  no  longer 
necessary.  Commercial,  off-the-shelf  products 
can  be  used  on  this  bus,  and  there  is  no  need 
to  verify  their  trustworthiness. 

Two  factors  argue 
against  designing  the  LOCK  with  a  single 
encryption  device.  The  first  is  performance. 
Splitting  the  functionality  between  two 
encryption  devices  minimizes  performance 
degradation.  The  second  reason  is  that  by 
having  a  separate  bulk  encryptor  with  minimal 
logic  surrounding  it,  the 
sensitive/nonsensitive  (red/black)  interface 
is  physical.  If  the  SED  were  used  to  encrypt 
the  host's  secondary  memory  of  communications 
port,  one  would  have  to  rely  on  the  system 
working  correctly  (and  prove  this)  to  ensure 
that  no  sensitive  (unencrypted)  data  were 
ever  written  to  the  nonsensitive  bus.  Placing 
an  encryption  device  in-line  allows  us 
assurance  (without  incurring  the  cost  of 
verifying  the  device  controller's  software) 
that  sensitive  data  will  never  be  mishandled. 

4 .  Memory  Management  Unit 

(MMU) 

The  MMU  for  the  LOCK  is 
the  commodity  Motorola  68B51  MMU.  The  host 
CPU  queries  SIDEARM  when  a  subject  first 
makes  a  request  for  an  object..  The 


appropriate  information  (the  global  object 
table,  kept  on  SIDEARM' s  hard  disk)  is 
checked  and  access  is  permitted  or  denied, 
based  on  DAC,  MAC,  and  type  enforcement 
constraints.  SIDEARM  then  loads  the 
information  into  the  MMU.  The  MMU  caches  the 
access  rights  returned  until  a  context  switch 
forces  the  flushing  of  the  cache.  This 
context  switch  happens  when  there  is  a 
subject  change  on  the  system  or  when  a  user 
effects  a  change  in  the  level  he  is 
processing . 

To  increase  security, 
customized  enhancements  to  the  MMU  are  being 
included  in  the  design.  Certain  master  mode 
code  (also  called  supervisor  state  or  ring-0 
code)  will  be  kept  in  protected  PROM's  on  the 
MMU,  addressable  only  when  the  machine  is  in 
master  mode.  Examples  include  portions  of 
the  interrupt  handler,  fault  handler,  and  the 
subject  manager. 


5.  Host-SIDEARM  Interface 

The  host  and  SIDEARM 
communicate  through  a  custom  interface  device 
called  the  host  interface  controller  (see 
paragraph  E.I.,  also  called  the  VP  front-end 
filter) .  This  device  encapsulates  the 
specific  electrical  and  protocol  requirements 
c?  the  host  computer  bus  and  acts  as  a  driver 
t  j  relay  cru  requests  to  SIDEARM  and  to 
receive  the  responses.  The  SIDEARM  interface 
controller  is  SIDEARM' s  equivalent  mechanism 
tor  receiving  the  requests  and  then  sending 
signals  back  to  the  host. 

F.  Interdependence  of  COMPUSEC 

and  COMSEC 

LOCK  contains  a 
cryptographic  subsystem  composed  of  two 
distinct  devices:  (1)  the  SIDEARM  encryption 
device  (SED)  and  (2)  the  bulk  encryption 
device  (BED) .  This  subsystem  is  also  called 
the  communications  security  (COMSEC) 
subsystem,  but  in  actuality,  secure 
communication  outside  the  system  is  only  one 
of  its  functions. 

The  embedding  of  COMSEC 
into  LOCK  was  made  possible  by  a  major 
advance  by  the  Development  Center  for 
Embedded  Cryptographic  Products  in  the 
development  of  generic  low-cost  COMSEC 
modules.  The  purpose  and  benefit  of  these 
modules  for  COMSEC  is  the  same  as  those  the 
SIDEARM  module  will  have  for  computer 
security  (COMPUSEC) . 

The  COMSEC  and  COMPUSEC  are 
interdependent  in  LOCK.  This  means  that  a 
subset  of  the  security  requirements  for  each 
is  attained  by  the  use  of  the  other.  In  the 
lingo,  this  makes  LOCK  an  information 
security  (INFOSEC  =  COMSEC  +  COMPUSEC) 
development . 

The  COMPUSEC  depends  on  the  COMSEC  for  memory 
encryption  to  increase  assurance,  UID 
encryption  to  close  a  covert  channel  (see 
paragraph  E.2.),  and  external  network 
i  ncryption  to  secure  information  leaving  the 
computer  system.  The  COMSEC  depends  on 
the  COMPUSEC  to  meet,  certain  requirements 
involving  the  control  of  the  COMSEC  and  to 
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provide  a  secure  environment  within  which  the 
COMSEC  can  operate.  Both  the  COMPUSEC  and 
COMSEC  systems  in  LOCK  are  critical  to 
meeting  the  complete  security  requirements  of 
information  in  a  general  system  of  computing 
devices. 

G.  Software 

Although  essentially  a 
hardware-based  approach,  LOCK  is  not  without 
software.  The  software  is  required  for  two 
reasons:  (1)  to  allow  flexibility  during 
prototyping  and  (2)  to  accommodate  mutable 
and  system-specific  security  requirements  for 
a  particular  computer  type  and  at  particular 
computer  sites.  The  first  requirement  is 
reduced  for  final  production  machines,  but 
maintainability  will  require  that  some 
portions  remain  in  firmware  (e.g.  physically- 
protected  ROM)  .  Much  of  the  generic 
functions  can  be  implemented  in  hardware. 


host  are  passed  through  the  KIS,  over  the 
host  bus  to  SIDEARM.  The  SIDEARM  then  queues 
and  fulfills  the  request  if  it  is  allowed  by 
the  security  policy. 

The  verification  of  the 
S I DEARM  software  must  be  extremely  rigorous. 
SIDEARM  is  intended  to  be  a  generic  device 
that  is  designed  once.  All  properties 
required  of  the  reference  monitor  (including 
simple-security,  the  *-property,  type 
enforcement  [see  paragraph  I.],  and 
conditional-non-interference  [see  paragraph 

H.2.])  must  be  shown  to  hold  for  all  SIDEARM 
software.  This  is  a  very  expensive  and  time 
consuming  process,  but  it  is  worthwhile  for 
A1  assurance  and  the  cost  and  time  impact  is 
minimized  since  SIPEARM  is  only  designed  and 
verified  once. 

2  .  Kernel _ Interface 

Software  QOS1 


There  are  four  major  blocks 
of  software  in  LOCK;  SIDEARM,  kernel 
interface  software  (KIS) ,  kernel  extensions 
(KE's),  and  the  host  operating  system  (UNIX) 
(see  Figure  g)  .  Each  block  is  discussed  in 
detail  below  in  terms  of  function,  content, 
interfaces  to  other  blocks,  and  verification 
considerations . 


Figuie  g 


1.  SIDEARM 

The  SIDEARM  software 
implements  the  LOCK  reference  monitor.  The 
SIDEARM  has  a  set  of  externally-visible 
operations  plus  internal  software  and 
databases  necessary  to  perform  its  task.  The 
exact  specification  of  the  visible  operations 
and  their  parameters  will  toe  specified  in  an 
Interface  Control  Document  to  be  released 
toward  the  end  of  1988. 

SIDEARM  will  contain 
several  thousand  lines  of  high  order  language 
software.  The  reference  monitor  function  of 
SIDEARM  is  implemented  by  several  major 
software  subsystems  managing  the  resources  of 
SIDEARM  and  implementing  the  instruction 
requests  from  the  host  (see  paragraph  E.I.). 


The  KIS  is  essentially 
the  driver  software  for  the  SIDEARM  device  on 
the  bus.  The  host  CPU  makes  security-related 
requests  of  the  SIDEARM  device  via  the  KIS. 
Normally,  device  drivers  are  implemented 
directly  by  the  host  operating  system. 
Because  this  software  must  operate  correctly 
for  the  TCB  to  function  properly,  this 
particular  device  driver  must  be  segregated 
from  the  operating  system  and  verified  to 
function  correctly  and  be  unbypassable .  In 
simple  terms,  the  KIS  is  the  connective 
software  that  allows  the  host  CPU  to 
communicate  with  the  SIDEARM. 

The  KIS  is  intended  to 
be  small  end  minimally  privileged.  Some  of 
the  functions  will  have  to  operate  m  master 
mode,  but  they  will  only  have  restricted 
access  to  the  TCB.  Innate  security-relevant 
operations  designed  into  the  host  CPU,  such 
as  interrupt  handling,  will  have  to  be 
performed  by  the  KIS. 

The  KIS  is  an 
intermediary  between  the  host  operating 
system  running  on  a  particular  host  CPU  and 
the  generic  SIDEARM.  As  such,  the  part  of 
the  KIS  interfacing  with  SIDEARM  will  be 
highly  machine-dependent  and  will  have  to  be 
customized  when  the  SIDEARM  is  ported  to 
different  machines.  The  resource  management 
portion  of  the  KIS,  on  the  other  hand,  should 
be  fairly  general  and  should  require  minimum 
rework  when  ported.  Furthermore,  the 
interface  to  the  KIS  should  remain  stable 
across  different  computers  and  within  the 
same  computer  when  porting  to  a  different 
operating  system. 


The  verification  of  the 
KIS  should  be  somewhat  simpler  than  that  of 
the  SIDEARM.  The  verification  is 
functionally-oriented  as  opposed  to  property- 
oriented,  as  in  the  case  of  SIDEARM.  One 
only  needs  to  verify  that  the  KIS  adheres  to 
some  low-level  properties.  For  example,  the 
KIS  must  be  shown  to  totally  clear  the  CPU 
registers  during  a  context  switch  to  ensure 
the  removal  of  all  residue  information. 


The  host  CPU  interfaces  to 
the  SIDE ARK  software  via  the  KIS.  The 
security-relevant  operations  executed  by  the 


3 .  Kernel  Extension  (KE) 

KE  1  s  implement 
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application-specific  and  machine -specif  ic 
portions  of  the  security  policy.  For 
example,  labelling  output  for  peripherals 
such  as  printers  and  terminals  is  highly 
dependent  on  the  type  of  device.  Yet  proper 
labelling  is  absolutely  imperative  to  MLS 
(see  paragraph  1.2.).  All  of  the  expensive 
controls  within  the  system  are  for  naught  if 
someone  can  determine  or  alter  the  label  of 
data  output.  If  that  occurred,  a  process 
could  then  wantonly  downgrade  information  to 
unclassified  by  improper  output  labelling. 
In  this  capacity,  the  KE  implements  the 
nongeneric  portion  of  the  TCB  so  that  the 
SIDEARM  can  be  architecture-independent. 

KE '  s  are  also  used  to 
implement  application-specific  security 
policy.  For  example,  a  computer  may  have  a 
KL3  DBMS.  A  DBMS  requires  extra  controls 
over  and  above  the  controls  imposed  by  the 
operating  system  to  restrict  inference  and 
aggregation,  All  application-specific 
extensions  to  the  security  model  cannot  be 
included  in  the  reference  monitor  simply 
because  the  reference  monitor  would  become 
too  large.  Further,  we  can  not  predict  all 
the  possible  policy  extension  required  for 
applications  as  yet  un-built. 

The  KE's  provide 
application-specific ,  security-related 
services  as  needed.  The  KE's,  therefore, 
interface  to  potentially  hostile  applications 
and  implement  their  special  services  at  the 
control  of  SIDEARM  via  calls  through  the  KIS. 
Since  KE's  capture  machine-specific  and 
application-specific  portions  of  the  TCB, 
they  will  be  minimally  portable  between 
different  types  of  LOCK  computer  systems. 

These  KE's  may  have 
some  privileges  not  associated  with  normal 
programs.  For  example,  a  downgrader  KE  has 
the  privilege  to  violate  the  ‘-property.  The 
KE's,  however,  are  only  given  the  privilege 
required  to  do  their  task  and  are  verified 
not  to  abuse  that  privilege.  In  short,  KE's 
are  the  flexible  part  of  the  TCB,  under 
strict  control  by  the  hardware  reference 
monitor  -  the  SIDEARM. 

4 .  UNIX 

The  operating  system  in 
LOCK  is  considered  hostile  code.  This  means 
that  the  operating  system  will  not  have  to  be 
reverified  and  recertified  after  updates  and 
changes  as  is  the  case  with  traditional 
software  kernel  approaches  to  computer 
security . 

Does  this  mean  you  can 
take  an  existing  operating  system  on  a 
machine,  retrofit  it  with  a  SIDEARM,  and 
simply  run  the  operating  system  unaltered? 
No!  Operating  systems  typically  perform 
security-related  functions  rooted  in  resource 
(CPU  time,  memory)  management.  These  parts 
of  the  operating  system  will  now  have  to  be 
performed  by  the  SIDEARM.  Therefore,  some  of 
the  operating  system  internals  will  have  to 
be  removed  and  replaced  by  calls  into  the  KIS 
which,  in  turn,  calls  the  SIDEA.RM. 

UNIX  was  chosen  to 
demonstrate  the  principles  of  LOCK  because  it- 
is  relatively  small  and  because  it  is  a 


popular  operating  system.  Since  the 
operating  system  is  treated  as  a  hostile 
application  and  the  interface  to  the  KIS 
should  be  fairly  stable,  the  implementation 
of  a  different  operating  system  on  the  LOCK 
base  should  not  prove  difficult. 
Furthermore,  once  the  KIS  is  developed  for  a 
different  computer  system,  the  modified  UNIX 
should  easily  port  to  the  new  computer 
system . 

What  about  applications 
software  portability?  Since  LOCK  is  intended 
to  be  an  A1  certifiable  computer,  the 
question  of  necessary  changes  to  the  UNIX 
System  V  interface  definition  arises.  It  is 
pretty  clear  that  it  will  not  be  possible  to 
leave  the  interface  completely  unaffected  and 
have  A1  security.  We  do  not  yet  know  what 
the  full  impact  to  the  operating  system  and 
applications  will  be.  It  is  our  goal  to 
minimize  the  impact  and  to  localize  it  so 
that  any  changes  necessary  in  porting  an 
application  from  an  unmodified  UNIX  to  our 
Secure  UNIX  will  be  reasonably  small  and 
perhaps  automatable. 

H.  Verification 

LOCK  is  using  the  Gypsy 
verification  environment  [GOOD78]  to  prove 
its  security  properties.  The  general 
approach  that  has  been  taken  is  to  prove  the 
system  top-down  in  conjunction  with  the 
system  design. [BOEB85a,  BOEB85d)  As  the 
design  is  refined  from  the  preliminary, 
highly  abstract  level  to  the  more  precise, 
detailed  level,  the  verification  proofs  arc. 
proceeding  at  the  same  pace  (or  even  slightly 
ahead  of  the  design)  and  are  used  to  feedback 
critical  design  issues.  These  issues  arise 
in  places  where  the  verification  team  is 
having  difficulty  proving  security.  Feedback 
will  show  where  the  team  can  simplify  the 
design,  making  the  proofs  easier  and 
conceptually  cleaner. 

The  use  of  type  enforcement 
(see  paragraph  I.)  makes  the  proof  of  the 
system  security  much  easier.  The  type 
enforcement  mechanism  allows  us  to  prove  the 
unbypassability  and  tamper  resistance  of 
process  modules.  By  proving  this  once,  we 
can  carry  the  lemmas  over  to  other  sections. 
This  allows  us  to  focus  on  the  correctness  of 
the  next  piece  we  must  prove.  It  also 
permits  a  much  greater  assurance  in  trusted 
processes,  as  their  privileges  may  be 
precisely  given,  and  thus,  restricted. 

There  are  three  established 
levels  of  proof.  The  abstract  model,  which 
is  very  general;  the  interpretation  level, 
somewhat  more  detailed;  and  the  formal  top 
level  specification  (FTLS) ,  the  most  detailed 
yet  (see  Figure  h).[HONE86]  The  FTLS  is 
complete  except  for  some  modifications,  and 
the  addition  of  most  of  the  kernel  extensions 
are  still  to  be  clone.  Along  with  these 
formal  proofs  is  a  Descriptive  Top  Level 
Specification  —  a  document  that  explains  the 
security-relevant  features  in  English 
narrative  statements. 


1 •  Formal  Implementation 
Level  Specification  (FTI.S^ 
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To  verify  that  this 
type  of  system  is  correct,  one  must 
explicitly  show  that  there  is  no  way  for  the 
user  to  hack  up  the  security  tables  or 
interfere  with  the  security  mechanisms  that 
are  in  place.  It  becomes  a  significant  task 
to  show  that  of  all  possible  programs,  no 
program  surreptitiously  modifies  any  of  this 
information.  Since  the  Central  Processing 
Unit  (CPU)  and  memory  resources  are  shared 
between  the  user  and  TCB,  there  is  ample 
opportunity  for  tampering  to  take  place  due 
to  the  lack  of  physical  separation. 

Performance  has  been 
the  high  price  paid  for  software  security 
kernels.  The  cause  of  performance 
degradation  is  the  multiplexing  of  resources 
between  the  operating  system  and  the 
reference  monitor  and  increased  overhead 
associated  with  frequent  context  switching. 
The  same  CPU  handles  all  of  the  security- 
related  processing  in  addition  to  the  normal 
processing  of  the  system  in  a  software 
implementation.  Memory  resources  are  also 
shared  in  a  software  implementation.  A 
portion  is  allocated  for  security-relevant 
information,  and  the  rest  is  used  in  the 
normal  course  of  processing.  This 
dramatically  increases  the  load  placed  on  a 
single  set  of  resources  and  decreases  the 
assurance  because  of  the  intermixing  of 
computational  and  security-related 
information.  A  context  switch,  the  complete 
replacement  of  processed  information  in  the 
CPU  required  by  a  change  in  subjects,  is  also 
a  tremendous  uidut  on  the  processing 
capability  of  the  computer.  These  factors 
have  degraded  the  performance  of  secure 
software  implementations  to  as  low  as  10%  of 
the.  unmodified  operating  system.  [GOLD84  ] 
Additionally ,  there  is  some  question  about 
the  level  of  assurance  gained  since  some 
applications,  like  database  management 
systems  (DBMS) ,  need  to  reach  directly  into 
the  machine  level  —  completely  bypassing  the 
security  mechanisms. 


As  mentioned  earlier, 
the  software  approach  involves  a  major 
redesign  or  restructuring  of  the  operating 
system  kernel.  Many  existing  application 
programs  require  certain  services  from  the 
operating  system.  The  entry  points  for  these 
services  often  must  be  redefined  when  the 
kernel  undergoes  such  significant 
modification.  The  loss  of  these  entry  points 
severely  limits  the  compatibility  of  the 
operating  system  with  existing  applications. 

Enhancing  an  operating 
system's  functionality  usually  involves 
making  changes  to  the  kernel.  Even  if  the 
changes  are  not  ostensibly  security-relevant, 
it  must  be  explicitly  shown  through 
verification  (or  revalidation  at  lower  levels 
of  security)  that  the  security  of  the  system 
has  not  been  affected  as  a  result  of  subtle 
interactions  between  the  software  modules. 
Currently,  verification  of  computer  systems 
is  expensive  and  time-consuming. 
Additionally,  no  claims  about  the  security  of 
the  new  operating  system  may  be  made  until 
that  version  of  the  operating  system  has  been 
evaluated,  a  time-consuming  procedure.  The 
decision  that  must  be  made  is  whether  to 
undergo  another  verification  and  evaluation 


or  to  continue  with  the  existing,  outdated 
operating  system. 

2 .  Hardware 

The  hardware-based 

approach  taken  by  the  LOCK  project  is  a  much 
closer  match  to  the  reference  monitor  model 
(see  Figure  b) .  The  problem  that  arose 
concerning  bypassing  the  reference  monitor  is 
eliminated  because  the  SIDEARM  is  a  separate 
processor,  with  its  own  memory,  that  is 
running  before  the  user's  processor  boots  up. 
In  addition,  the  security  mechanisms  and 
tables  are  self-contained  within  the  SIDEARM, 
thereby  making  the  system  verification 
easier.  Because  SIDEARM  is  a  separate 
resource,  there  is  no  physical  way  for  the 
user  to  access  this  memory;  it's  trivial  to 
verify  that  the  user  can't  alter  the 
security-relevant  information.  Finally,  a 
user  cannot  initiate  a  process  that  will 
tamper  with  the  security-relevant  operations 
because  none  of  SIDEARM 's  processing 
resources  are  under  control  of  the  user. 
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Figure  b 


The  design  approach 
taken  by  the  LOCK  project  is  rigid  resource 
separation  (see  Figure  c) .  The  computational 
and  security  resources  are  segregated  at  the 
system  design  level,  and  this  segregation  is 
carried  down  to  the  physical  implementation. 
This  approach  yields  two  significant 
benefits.  First,  unbypassibility  is 
guaranteed  by  SIDEARM  having  exclusive 
possession  of  object-addressing  information 
and  exclusive  control  over  the  memory 
management  unit  (MMU )  (see  paragraph  E.4.). 
Second,  the  physical  separation  prevents  any 
tampering  on  the  part  of  the  user. 

LOCK  will  initially  be 
a  set  of  boards,  but  our  goal  is  to  reduce 
this  down  to  a  chip  or  set  of  chips  by  using 
either  very  large  scale  integration  (VLSI)  or 
very  high  speed  integrated  circuitry  (VhSIC) 
technology . 


D •  System-Independent.  Domain- 
Enforcing,  Assured  Reference  Monitor 
f  SIDEARM! 

SIDEARM  is  the  hardware 
instantiation  of  the  reference  monitor  and  is 


the  heart  of  the  LOCK  technology  development 
effort.  SIDEARM  is  a  separate  embedded 
computer,  v/ith  its  own  processors  and  memory, 
that  controls  the  resources  of  the  host 
computer  by  mediating  all  accesses  to  those 
resources  by  users  operating  on  the  host  CPU 
(see  Figure  d) . 


identifications  and  security  attrioutes ;  and 
(3)  it  is  guaranteed  not  to  be  bypassed 
because  it  will  be  physically  impossible  for 
the  CPU  to  address  its  own  memory  without 
going  through  the  SIDEARM  to  get  the  object's 
address.  These  databases  and  operations  are 
all  independent  of  the  host  system. 
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SEGREGATION  OF  SECURITY -RELATED  RESOURCES  IS  KEY 

•  SIMPLIFIES  VERIFICATION 

•  PHYSICALLY  ENFORCED  SEPARATION  PREVENTS  TAMPERING 

.  REPERENCE  MONITOR  INVOKED  ON  EVERY  PROCESSOR  ACCESS 

Figure  c 


REFERENCE  MONITOR  IN  LOCK 
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Figure  d 


Our  goal  is  to  develop  a 
generic  SIDEARM  module  that  is  independent  of 
the  computer  system  it  monitors.  This  does 
not  mean  that  it  will  be  a  black  box  that  one 
magically  affixes  to  the  cabinet  of  the  host 
computer,  making  it  automatically  secure. 
Rather,  the  intent  is  to  minimize  the 
replication  of  work  when  securing  different 
computers  and  operating  systems  by  '-"Dturing 
the  essence  of  the  TCB  the  'erence 
monitor  -  in  a  generic  a.  T  achine- 
specific  requirements  involving  the 
connection  of  the  SIDEARM  module  to  a 
particular  computer  are  reasonably  small  and 
modularized  to  interfaces  that  can  be 
customized . 


SIDEARM  has  three  i  ..  .tant 
properties  making  it  generic:  (1)  i  -..anages 
the  identification  and  security  labeling  of 
all  objects  and  subjects;  (2)  it  implements 
the  mandatory  security  policy  based  on  these 


The  security  databases  and 
operations  are  not  only  generic,  but  they 
allow  for  a  very  flexible  and  powerful 
security  policy.  For  example,  the  dominance 
'-elationship  which  determines  access  between 
subjects  and  objects  [BEL675]  will  be 
implemented  as  an  explicit,  partial  ordering 
data  structure.  This  means  that  the  security 
lattice  (actually,  Partially  Ordered  set  or 
POSet)  can  be  dynamic,  limited  to  points  in 
the  lattice  that  are  truly  needed,  and  have 
multiple  roots,  thereby  getting  rid  of  the 
dangerous  concept  of  "system  high . " [ FERG86] 

The  purpose  of  developing 
the  SIDEARM  module  is  to  provide  vendors  with 
a  foundation  for  computer  security  that  they 
can  use  to  minimize  the  cost  and  time 
required  to  secure  their  own  computers.  No 
longer  will  the  vendors  have  to  become 
Criteria  lawyers  to  interpret  each  and  every 
Criteria  requirement  for  their  system - 
SIDEARM  will  be  precertified  to  meet  a  base 
percentage  of  the  information  security 
requirements.  It  only  remains  to  demonstrate 
that  the  module  has  been  hooked  into  their 
computer  system  correctly  and  that  the 
remainder  of  the  requirements  not  met  by  the 
SIDEARM  module  are  implemented  by  the  host 
system. 


Providing  seed  money  for  the 
initial  development  is  our  way  of  encouraging 
industry  to  bo*,  i  produce  these  devices  and 
use  them  in  securing  their  own  products. 
Within  LOCK,  a  s I DEARM  module  will  be 
retrofitted  to  an  existing  computer  as  a 
proof-of-pri nciple  of  the  generic  nature  of 
the  module  and  as  a  worked  example  of  how  a 
retrofit  is  done.  This  information  will  be 
made  available  to  vendors  wishing  to  retrofit 
their  own  computers  using  SIDEARM  modules. 

Finally,  we  will  publish  the 
documentation  on  the  interface  to  the  SIDEARM 
module,  and  vendors  designing  their  next- 
generation  computers  can  incorporate  the 
capability  to  insert  the  SIDEARM  module  into 
their  new  systems  without  the  expense  of 
retrofit  changes.  In  summary,  SIDEARM  is 
intended  to  secure  the  nation's  computer 
systems  cheaply  and  efficiently  at  a  very 
high  level  of  assurance. 


E.  The  Architecture 

Honeywell's  XPS  100/20 
computer  will  be  the  platform  for  the  LOCK. 
The  XPS  100/20  is  an  MC68020  microprocessor- 
based  computer  with  a  VME  bus  architecture, 
running  UNIX  System  V. 

The  XPS  100/20  was  chosen 
for  two  reasons.  A  study  of  three  different, 
popular,  32-bit  microprocessors  [HONE86] 
found  that  the  MC68020  has  a  flexible 
coprocessor  interface  that  makes  it  easy  to 
adapt  to  the  requirements  of  LOCK  technology. 
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•  REPROOF  OF  SPECIFICATION  AT  EACH  LEVEL 

•  MAPPING  BETWEEN  EACH  LEVEL 

•  criteria  REQUIREMENTS  stop  AT  THE  FTLS  LEVEL  OF  DETAIL 
Figure  h 


Although  the  Criteria 
calls  for  the  FTLS  to  be  the  lowest  level  of 
proof,  the  LOCK  team  will  probe  to  a  deeper 
level.  This  next  level  we  call  the  Formal 
Implementation  Level  Specification  (FILS) . 
Whereas  the  FTLS  presents  the  TCB-user 
interface  without  the  details  of  how  that 
.interface  is  implemented,  the  FILS  delves 
into  the  implementation  detail  or  the 
internal  workings  of  the  TCB-  The  FILS  will 
essentially  be  a  very  detailed  specification 
for  the  TCB  and  related  code.  This  level  of 
detail  will  also  facilitate  the  required 
specif ication-to-code  mappings. 


2. 


The  proofs  of  security 
are  based  on  Goguen  and  Meseguer's  notion  of 
noninterference. [G0GU84]  The  noninterference 
model  is  an  infor»ation-based  model  as 
opposed  to  an  access  control  based 
model . [BELL75]  Simply  stated, 
noninterference  requires  proof  that  a  subject 
cannot  interfere  with  anything  a  lower-level 
subject  can  view  in  the  system.  This 
prevents  any  flow  of  information  (assuming 
the  security  system  is  modeled  correctly  and 
completely)  from  a  high  to  a  low  level  and 
thus  clos  s  many  covert  channels  that  would 
exist  in  access  control  based  models. [HAIG8 6] 

The  proof  of 
noninterference  is  based  on  a  recently- 
developed  unwinding  theorem.  The  verifier 
must  prove  that  the  low-level  subject's 
output  from  his  instructions  are  not  affected 
if  the  corresponding  instructions  from  a 
high-level  subject  are  deleted  from  the 
instruction  stream  being  input  to  the 
reference  monitor.  Since  strict 
noninterference  would  severely  inhibit  system 
operability,  the  LOCK  verifiers  will  be  using 
a  modified  form  of  neninterf erence  called 
conditional  noninterference.  This  stateG 
that  the  low-level  subject's  output  is  not 
affected  except  in  specific  instances.  These 
instances  will  be  the  only  place  where  covert 
channels  may  occur,  assuming  perfectly 
faithful  implementation  of  design. 

The  LOCK  effort  will 
also  produce  a  covert  channel  analysis  tool 
using  the  shared  resource  matrix  methodology 
in  conjunction  with  a  Gypsy  flow  analyzer. 
This  tool  will  be  used  on  those  sections 
where  the  noninterference  proofs  cannot  be 


proved  easily  and  will  identify  the  covert 
channel  involved.  While  it  will  fail  where  a 
covert  channel  exists,  noninterference  does 
not  identify  the  channel  -  hence  the  need  for 

this  tool. 

Noninterference  is 
applied  both  in  the  multilevel  security  sense 
and  in  the  multidomain  (see  paragraph  1. 1.) 
security  sense.  A  noninterference  proof  is 
sufficient  to  assure  proper  access  control 
and  the  absence  of  covert  channels  between 
classification  levels  and  between  different 
domains.  This  allows  the  type  enforcement  to 
be  just  as  "tight"  security-wise,  as  MAC. 

An  auxiliary  step  in 
the  verification  process  will  be  for  the  LOCK 
verifiers  to  couch  selected  Gypsy  proofs  in 
mathematical  journal  level  language  and 
submit  them  to  a  social  review 
process .[ BOEB85d]  This  allows  the  proofs  to 
be  looked  at  by  someone  not  necessarily 
familiar  with  the  intricacies  and 
peculiarities  of  automated  theorem  provers, 
as  well  as  forcing  us  to  give  a  less  abstruse 
or  esoteric  proof. 

I.  Type  Enforcement 

Type  Enforcement  is  LOCK'S 
way  of  providing  mandatory,  configurable 
integrity.  Both  DAC  and  MAC  may  be  thought 
of  as  mechanisms  that  restrict  access  to 
information.  Type  enforcement  is  just 
another  restriction  placed  upon  the  results 
of  the  first  two.  Access  rights  are  whatever 
passes  the  three  "filters."  Type  enforcement 
relies  on  the  use  of  levels  anu  labels  on 
subjects  and  objects  and  has  rules  to  permit 
access.  This  information  is  encoded  within  a 
matrix  similar  to  the  normal  MAC 
matrix. [B0EBS5b] 

1 .  Domain _ Definition 

Table/Domain  Transition  Table  DDT/DTT 

Type  enforcement  relies 
on  two  data  structures:  the  DDT  and  the  DTT. 
The  DDT  is  a  matrix  with  "types"  on  one  axis 
and  "domains"  on  the  other.  The  intersection 
is  the  set  of  privileges  (possibly  null)  a 
subject  within  a  particular  domain  has  to  an 
object  of  a  particular  type.  The  DTT  is  a 
matrix  with  "subject"  labeled  on  both  axes; 
"subject,"  in  LOCK  terminology,  is  a  user- 
domain  pair.  The  intersection  is  a  simple 
"yes"  or  "no,"  indicating  whether  a 
particular  user  in  a  particular  domain  may 
transition  to  a  different  domain. 


The  DDT/DTT  may  be 
configured  such  that  an  "assured  pipeline"  is 
created.  This  is  a  control  structure  wherein 
an  object  is  input  to  the  lead  control 
process,  undergoes  some  intermediate 
processing,  and  is  finally  output  in  a 
"refined"  form.  The  LOCK  has  the  ability  to 
insure  that  no  unauthorized  process  may 
contaminate  the  object  as  it  moves  through 
this  pipeline. 


An  example  of  such  a 
construct  would  be  a  system  where  all  the 
output  from  a  printer  is  labeled  with  the 
proper  classification  label  (as  required  by 
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DOWNGRADER 


the  Criteria) .  One  desires  a  system  where  it 
is  easy  to  prove  that  text  to  be  printed  is 
labeled  before  being  printed.  Also,  one  has 
to  prove  that  no  information  may  be  printed 
without  being  labeled,  and  that  no  process 
can  change  the  label  on  a  labeled  file  before 
it  is  printed. 

The  setup  for  the  DDT 
is  shown  in  Figure  i.  Any  normal  user  may 
read  and  write  to  something  called  "raw 
text."  When  he  wishes  to  print  this,  the 
labeler  may  read  from  this  object  (type:  raw 
text)  and  write  to  an  intermediate  object 
(type:  labeled-for-printer  text) .  The 

printer  may  read  only  from  objects  of  typo 
labeled-for-printer  text.  No  other  rights 
for  the  two  types  are  given  to  any  other 
domain.  This  forces  objects  to  be  labeled 
before  being  printed  and  assures  us  that  only 
the  labeler  has  touched  the  label.  A 
graphical  representation  appears  in  Figure  j . 


LABElEDFOR  printer 

RAW  TEXT  TEXT  PRINTER 


USER 

DOMAIN 


LARELER 

DOMAIN 


PRINT 

SPOOLCR 

DOMAIN 


THE  IMPLEMENTATION  Ol  THE  ASSURED  PIPELINE 
MERILY  REQUIRES  AN  APPROPRIATE  CONFIGURATION 
'■3urS  I  OF  THE  DOMAIN  DEFINITION  TABLE- 


LABELCU-rOn-PHIMlER 

HAW  TEXT  TEXT  PRINTER 


Figure  j 


Another  pipeline  that 
illustrates  the  utility  of  the  assured 
pipeline  is  the  downgrader  example  (see 
Figures  k  &  1)  .  This  can  be  viewed  as  a 
triple  turn-ley  operation.  If  the 

downgrader,  the  reviewer,  and  the 
instantiater  are  all  different  users,  it 
requires  that  all  three  take  some  positive, 
specified  action  to  allow  the  object  to  be 
downgraded. 


TO  DI.-UUWNUUAULU  DELTA  Tilt  Ml  W-VLnSlOU  I  INAL 


•  [TOWNGRAPLFT  --  CRLATCS  TIFTST  DRAI  T  OT  CHANCES  RLQUIMED 
TOR  DOWNGRADING 

•  FTEVIEWFFT  --  COMPOSES  URAFT  WITH  ORIGINAL  AND  OPTIONALLY 
CHEAT  LS  A  RLVI5ION 

•  IWST  ANT  I  AT  F-R  REVIEWS  OITA!  T  2  AND  PERI  OHMS  THE  ACTUAL 
DOWNGRADE 


Figure  1 


Encapsulation 
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Type  enforcement  and 
the  ability  to  construct  an  assured  pipeline 
leads  to  an  important  encapsulation  for 
verification  purposes.  Once  the  type 
enforcement  is  proved  to  work  correctly, 
other  proofs  may  use  type  enforcement  to 
satisfy  some  security  properties.  Type 
enforcement  may  be  used  to  satisfy  the 
nonbypassability  requirement  as  well  as  the 
tamper-proof  requirement,  since  subjects  are 
restricted  from  accessing  certain  objects  by 
the  DDT  and  this  concept  can  be  extended  to 
provide  the  pipeline  effect,  it  can  be  shown 
which  processes  will  have  what  access  to  what 
information  in  a  very  precise  manner.  It  is 
possible  to  have  a  single  program  occupy  a 
domain.  This  level  of  granularity  is 
unmatched  by  MAC  and  is  unmatched  by  DAC  in 
assurance .[ BOLB85C )  A  proof  of  the  type 
enforcement  mechanism,  then,  leads  to  a 
simplified  proof  of  two  of  the  three 
properties  for  modules  in  a  reference 
monitor. 


LOCK  Amplications 


As  mentioned  earlier,  LOCK 
will  be  useful  for  different  applications. 
In  some  cases,  it  will  be  necessary  to 
provide  more  than  the  generic  portion, 
SIDEARM,  to  suit  the  needs  of  the  user 
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completely.  KE 1  s  will  be  the  mechanism 
employed  to  extend  the  generic  portion  to 
handle  the  specific  applications.  This 
allows  the  computer  system  designer  to 
incorporate  only  the  functionality  that  is 
required  by  the  users.  For  example,  if  the 
system  will  not  be  connected  to  a  computer 
network  in  its  life  cycle,  it  would  be 
unnecessary  to  incorporate  secure  networking 
functionality.  The  KF  mechanism  is  a  cost 
effective  solution  in  addition  to  being  an 
efficient  means  for  implementing  security 
functionality.  Providing  only  the  necessary 
security  functionality  eliminates  the  cost  of 
additional  bells  and  whistles  not  needed  in 
particular  implementation.  Similarly,  the 
addition  of  only  the  necessary  KE 1 s  does  not 
trigger  exponential  cost  increases.  Such  is 
not  the  case  for  systems  that  incorporate 
mechanisms  to  handle  all  possible 
application-specific  security.  Another  cost- 
reduction  factor  is  that  the  KE's  are 
verified  and  certified  to  the  extent  that 
they  perform  their  job  correctly  and  are 
dynamic  entities  that  can  be  added  without 
causing  the  entire  system  to  undergo 
reverification  and  reevaluation. 

The  type  enforcement 
mechanism  allows  the  encapsulation  of 
subsystems  and  the  implementation  of  assured 
pipelines.  This  makes  the  development  of 
multilevel  applications  much  easier  in 
addition  to  providing  a  higher  degree  of 
assurance.  Currently,  three  ongoing  efforts 
demonstrate  LOCK'S  applicability  and  are 
described  below. 

1.  BLACKER 

The  BLACKER  project 
provides  multilevel  security  for  packet- 
switched  computer  communication  networks 
through  the  use  of  a  front-end  interface 
between  the  host  computer  and  the  network. 
BLACKER  achieves  network  security  by 
maintaining  secure  electronic  key 
distribution  as  well  as  end-to-end 
encryption.  while  BLACKER  provides  security 
between  computers,  LOCK  provides  security 
within  the  computer.  The  KE  mechanism  within 
LOCK  can  be  usee-  to  emulate  the  BLACKER 
functionality  to  allow  secure  computers  to 
communicate  securely.  The  specifics  required 
by  BLACKER  can  be  incorporated  into  a  KE 
designed  to  provide  the  necessary 
functionality  for  communication  on  a  BLACKER 
network  if  desired. 

2 .  Secure  Data  Network 

System  fSDNSl 

The  SDNS  project  is  a 
strategy  for  securing  communications  over 
public  data  networks  through  end-to-end 
encryption.  The  manner  in  which  this  is  done 
is  vastly  different  than  that  employed  by  the 
BLACKER  project.  SDNS  utilizes  a  different 
form  of  key  management  and  distribution  than 
the  one  imp] emented  by  BLACKER. 

A  major  contribution  of 
the  SDNS  project  is  a  user-friendly,  user- 
transparent  key  management  technology.  This 
key  management  strategy  does  not  employ  any 
access  control  functionality.  SIDEARM,  the 
foundation  of  LOCK,  provides  a  very  rich 


access  control  facility  capable  of  handling 
this  task  without  the  addition  of  an  access 
control  module.  An  SDNS  KE  would  have  to  be 
specified,  verified,  and  implemented  to  allow 
communication  on  an  SDNS  network.  Transition 
between  the  two  forms  of  secure  networks 
discussed  above  becomes  a  matter  of  using  the 
BLACKER  KE  set  or  the  SDNS  KE  set. 

Eventually,  the 

technology  produced  in  this  effort  will 
undergo  a  Commercial  COMSEC  Endorsement 
Program  (CCEP)  security  product  development 
[BARKS 6 ]  to  provide  the  opportunity  for 
industry  and  government  to  develop  a  security 
chitecture  compatible  with  the  Open  Systems 
Interconnection  network  model  [ZIMM80] 
developed  by  the  International  Standards 
Organization. 


3  .  Secure  Distributed  Data 

Views  ( SDDV) 

The  Honeywell  SDDV 
project  is  a  multilevel  secure  relational 
database  management  system  (MLS/DBMS) 
designed  to  run  on  the  LOCK  TCB.  Secure 
database  systems  are  application  software 
that  manage  large  amounts  of  information  at 
different  classification  levels.  The 

MLS/DBMS  security  policy  is  developed  as  an 
extension  to  the  LOCK  base  policy  and  will  be 
implemented  via  the  KE  mechanism.  SDDV  will 
demonstrate  the  advantages  of  LOCK  for 
de /eloping  MLS  applications  as  it  is  the 
first  application  built  upon  the  J.OCK 
foundation.  The  type  enforcement  mechanism 
isolates  the  components  of  the  DBMS,  making 
the  operations  fairly  simple  extensions. 
SDDV  takes  advantage  of  the  assured  pipelines 
and  the  modular  structure  that  LOCK  provides 
to  implement  the  kernel  extensions  in  a 
secure,  flexible,  and  functional  manner  (see 
Figure  m)  .  SDDV  is  contracted  by  the  Air 
Force  Rome  Air  Development  Center  (RADC)  to 
the  Honeywell  Secure  Computing  Technology 
Center  and  Stanford  Research  Institute. 
Success  of  the  Honeywell  effort  depends  upon 
the  LOCK  technology  being  fully  developed. 


ASSURED  PIPELINES 


NON-DBMS  j  DBMS 

DOMAINS  ■  DOMAINS 


Figure  m 
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ABSTRACT 

As  an  emerging  operating  system  standanl.  UNIX  is  being  used  more  and  more  as  a  basis  foi  building  secure  syMsli.s. 
1„  uue  1980  ihe  National  Computer  Security  Center  (NCSC)  studied  a  prototype  seam-  sy-icm  dct.vcd  Horn  MM. 
System  V,  Release  2  version  ol  UNIX.  The  study  assessed  that  system's  compatibility  with  the  »*-  asstnaiK, 
requirements  defined  in  the  Tmsted  Computer  System  evaluation  Criteria  (T'CSl.C).  The  study  also  pave 
insipht  into  the  meaning  of  and  relationships  among  those  requirements.  Ilus  paper  pivsents  the  results  ot  tin  stud, 
and  some  advice  for  builders  ot  systems  intended  to  meet  the  112  requirements. 

The  views  and  opinions  expressed  in  tins  paper  are  solely  those  of  the  authors  and  do  not  necessarily  rvllea  olhcial 
National  Computer  Security  Center  positions.  In  particular,  ibis  paper  should  not  tv  consul  .red  as  an  othual  Intuit 
Interpretation  for  any  TCSUC  requirements. 


INTRODUCTION 

Last  year,  the  NCSC  perfonned  an  extensive  study  of  the  implementation 
of  n  prototyiv  secure  system  based  on  AT&T's  System  V.  Release  2  ver¬ 
sion  of  UNIX.  The  study  was  performed  by  a  live-person  learn,  including 
exports  in  UNIX,  operating  system  design,  and  security  evaluation,  dur 
ing  eight  weeks  in  ihc  fall  of  198(v  The  purpose  ol  this  study  was  to 
evaluate  die  suitability  of  the  generic  UNIX  system  architecture  as  a  base 
for  building  secure  systems.  Although  the  study  was  primarily  concerned 
with  a  single  example  system,  the  team  attempted  wherever  possible  to 
generalize  the  results  to  oilier  versions  of  UNIX. 

This  paper  discusses  why  the  study  was  conducted,  why  the  112  level  ot 
the  TCSF.C  [DoD85)  was  chosen  and  what  requirements  of  the  1'CSLC 
were  considered.  It  then  presents  a  definition  of  modularity  that  w  as  used 
in  die  analysis  ol  UNIX  and  repons  tlie  results  ol  applying  that  definition, 
including  several  specific  examples  common  to  most  UNIX  systems  The 
paper  concludes  with  recommendations  on  how  to  approach  development 
of  112-class  systems. 


Outline  of  the  Study 

The  NCSC  is  evaluating  several  UNIX-based  ot  UNIX-like  systems  at 
various  TCSP.C  levels  and  expects  to  he  evaluating  more  in  the  future. 
This  study  was  undertaken  in  the  interest  ol  ensuring  that  similar  systems 
be  evaluated  consistently  The  NCSC  fonned  the  study  team  to  evaluate 
the  internals  of  one  ol  these  candidate  systems  in  depth  The  purpose  of 
the  study  was  not  to  examine  the  particular  system's  security  leatures  for 
sufficient  implementation,  hut  rather  to  evaluate  how  well  the  candidate 
system  and  generic  UNIX  systems  meet  the  architecture  requirement  and 
provide  assurance  of  secure  operation. 


This  work  was  supported  in  pan  by  the  National  Computer  Senility  Center 
under  Tusk  Order  Number  MDA903  84  C(X1.M:T-J5  XXX  issued  to  the  Institute 
for  Defense  Analysis 

UNIX  is  a  registered  trademark  of  AT&T. 


While  the  study  focused  on  a  specific  system, 
cable  m  niosi  svcuiuy-eiiiiaiiccd  UNIX-base, 


the  results  do  appear  appli 
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sense,  are  applicable  lo  all  systems  targeted  for  the  B2  level  or  higher. 
The  results  specific  to  UNIX  are  applicable  to  any  system  built  by  mi  di- 


lying  a  standard  release  of  UNIX  lo  ;uld  security  leatures  without  a  .  om 


plete  internal  restructuring  both  within  the  kernel  and  without. 


The  study  leant  concluded  thai  ii  is  possible  to  build  a  B2, 1U,  or  A1  sys¬ 
tem  with  an  interlace  very  much  like  that  ol  UNIX.  However,  il  also  con¬ 
cluded  dial  major  problems  exist  with  today's  common  UNIX  implemen¬ 
tations.  The  study  also  provided  valuable  insights  into  the  meaning  of  the 
D2  architecture  and  other  assurance  requirements,  which  are  applicable 
for  any  candidate  112  (or  above)  system,  not  just  UNIX-based  systems. 


Why  the  112  Requirements 

The  choice  ol  H?  as  a  target  level  for  the  analysis  was  not  arbitrary. 
Budding  a  111  system  is,  in  principle,  straightforward,  since  HI  primanly 
requires  features,  not  assurances.  The  intent  of  the  Ill  rating  is  to  cstab 
lish  a  target  that  can  be  readied  by  modifications  to  many  existing  sys 
tents,  while  still  providing  mandatory  access  control  leatures. 

A  H  I  level  analysis  w  as  not  considered  because  of  tlx-  stringent  require 
incuts  for  system  structure  and  minimal  TUB  complexity.  It  seemed 
unlikely  that  a  UNIX  based  system  would  even  approach  this  level  of 
layetmg  and  minimization  except  through  complete  reiniplemeulation. 

Il  seemed  possible,  however,  dial  the  112  level  could  he  achieved  in  a 
UNIX-based  system  without  wholesale  re-implementation.  Although  B2 
is  intended  as  ail  evaluation  class  for  systems  designed  from  the  Ix'gin 
ning  with  security  assutanees  in  mind.  UNIX  is  aiming  the  lew  existing 
systems  that  could  possibly  lx-  adapted  to  include  those  assurances 
without  a  complete  reiniplementalion  ol  its  liusied  Computing  Base 
(TUB).  UNIX  systems  have  already  served  as  an  implementation  base  ot 
interface  standard  for  many  computer  security  research  projects  (UC  LA 
Data  Secure  UNIX.  KSOS,  SCOMP  UNIX  emulator). 


1-12 


The  study  team’s  primary  focus  was  on  System  Architecture,  ami  modu¬ 
larity  in  particular,  where  the  System  Architecture  requirement  calls  for 
'‘wcll-delined,  largely  independent  modules.”  The  modularity  of  a  sys¬ 
tem  is  fundamental,  and  cannol  be  improved  simply  by  adding  Icaturcs. 
Modularity  is  also  relatively  independent  of  the  hardware  base  and  even, 
for  the  most  part,  of  the  strategy  for  adding  security  features.  Tile  modu¬ 
larity  analysis  represented  the  bulk  of  the  team's  effort,  and  its  results  are 
presented  in  the  next  section  (‘‘UNIX  MODULARITY”). 

All  of  the  B2  functional  requirements,  and  to  a  large  degree  even  the. 
other  assurance  requirements  firesides  System  Architecture),  arc  con¬ 
cerned  with  aspects  of  the  system  which  arc  likely  to  differ  substantially 
m  different  implementations.  Since  the  team’s  charter  was  limited  to 
studying  aspects  of  the  system  which  could  be  considered  "generic”,  and 
common  to  most  UNIX-based  secure  systems,  no  consideration  was 
given  to  specific  sccunty  features  of  the  examined  system  or  to 
implementation-dependent  assurances.  Only  those  aspects  which  arc 
largely  independent  of  any  one  implementation  were  examined;  this 
included  several  assurance  areas  in  addition  to  architecture,  and  these  arc 
discussed  in  the  “Additional  Assurance  Areas' '  section  below.  The 
remaining  assurance  areas  (such  as  covert  channel  analysis,  formal 
model,  testing,  and  configuration  management)  were  found  to  be  too 
specific  to  a  particular  system's  design  and  implementation  for  a  generic 
analysis  to  have  much  meaning. 


UNIX  MODULARITY 

Most  of  the  study  team’s  analysis  reviewed  modularity  and  independence 
of  die  components  of  die  UNIX  kernel,  along  with  some  of  the  trusted 
processes  (eg.,  mkdir.  printer  spooler).  A  definition  of  modularity  had  to 
he  chosen  and  a  determination  made  on  how  it  could  be  applied  lo  the 
UNIX  system.  Thai  definition  was  used  to  evaluate  TCB  components. 
The  study  team  conducted  a  detailed  analysis  of  nearly  one  third  of  the 
UNIX  TCB,  and  examined  most  of  the  rest. 

The  first  part  of  the  assessment  required  choosing  a  definition  for  “modu¬ 
larity”  and  applying  it  to  the  system.  Modulanty  can  be  present  at  many 
levels.  At  a  very  low  level,  the  instruction  opcodes  of  a  processor  could 
he  considered  "modules."  At  a  very  high  level  of  abstraction,  the  entire 
kernel  could  be  considered  a  “module"  whose  interface  and  parameters 
are  described  by  the  DTI.S.  To  understand  a  system,  an  appropriate  level 
of  abstraction  must  be  chosen,  and  this  proved  rathei  difficult.  The  team 
wanted  to  look  at  an  abstract  level  of  "major  subsystems"  m  die  kernel 
(such  as  lilt  I/O,  directory  management,  memory  management  |P>ach86)) 
but  found  this  to  be  iinpraelieal.  Although  the  existence  of  such  subsys¬ 
tems  tan  be  argued  from  a  functional  standpoint,  no  such  clean  boun¬ 
daries  exist  within  the  kernel  Instead,  many  individual  functions  directly 
manipulate  whatever  data  structures  they  must  to  "gel  die  job  done.”  In 
the  absence  of  more  abstract  modules,  llic  team  was  forced  to  use  a  lower 
level  of  abstraction.  This  less  abstract  view  required  rivaling  individual 
('-language  functions  (and  occasional  assembler-coded  functions)  as 
modules  and  evaluating  them  against  their  definition.  This  choice  was 
made  largely  because  die  functions  were  readily  identifiable  in  the  source 
code. 

The  study  team  also  started  with  a  definition  of  "modularity"  that 
claimed  modularity  is  independent  of  packaging.  In  theory,  this  is  rea¬ 
sonable,  but  the  originally  poor  packaging  of  the  system  and  of  the  code 
added  to  support  security  features  made  this  claim  unsupportahle.  The 
packaging  problems  make  the  system  more  difficult  lo  maintain,  thus 
resulting  in  potentially  lower  security.  The  packaging  also  made  it  very 
difficult  lo  identify  mo,  s  at  a  higher  level  of  abstraction  than  a  single 
function,  since  it  was  a  t  impossible  lo  find  all  ol  die  components  ol 
die  more  abstract  module. 

Ultimately,  the  team  concluded  that  modulanty  must  not  only  be  present, 
hut  must  also  be  readily  apparent  to  a  skilled  observer.  Midden  modular¬ 
ity  is  ol  no  value;  lor  instance,  an  uncommented  disassembly  listing  of  a 


system  which  is  fully  modular  in  its  high-level  language  form  could  nnt 
be  considered  modular  evert  though  die  two  fornis  arc  completely 
equivalent  from  the  machine's  point  of  view.  Modularity  cannot  be  just 
an  artifact;  it  must  be  an  expressed  and  evident  intention.  It  must  be 
present  !n  the  implementation,  supixirted  by  die  design  documentation, 
and  maintained  Uirough  die  configuration  management  system. 

Definition  of  Modularity 

'Hie  team’s  original  working  definition  of  "module”  was; 

“...a  conceptual  building  block  that  corresponds  to  the  work 
assignment  of  a  programmer  or  programming  team  ...  a  group 
of  doscly  related  programs." 

As  described  above,  howe.vc,  this  definition  proved  very  difficult  to  use. 
The  “work  assignment"  model  is  too  vague.  Because  of  the  extensive 
use  of  global  variables  in  the  kernel,  very  large  parts  of  the  kernel 
become  closely  related  The  "modules"  dial  result  from  this  definition 
were  too  large  and  too  diverse  functionally  to  be  considered  modular. 

Therefore,  in  the  basic  analysis  of  the  system,  the  team  used  a  module 
definition  similar  to  Stevens,  Myers  and  ConstantinciStcvens74j,  in 
which  a  module  is: 

"a  set  of  one  or  more  contiguous  program  statements  having  a 
name  by  which  other  pares  of  the  system  can  invoke  it  and 
preferably  having  its  own  distinct  set  of  variable  names." 

The  basic  a-  '  -jmption  of  the  analysis  was  that  if  all  die  modules  in  an 
operating  system  met  the  following  criteria,  the  system  could  be  con¬ 
sidered  fully  modular.  A  module; 

•  perfonns  exactly  one  well-defined  function; 

•  bas  wcll-delined  parameters,  interface  and  environment; 

•  interacts  with  other  mcxlulcs  only  in  wcll-delined  ways;  and 

•  is  called  upon  to  perform  its  function  whenever  that  function  is 
required. 

The  first  criterion  means  that  a  module  should  not  combine  multiple  func¬ 
tions,  particularly  if  they  arc  unrelated  or  arc  also  performed  in  other 
modules,  and  also  that  the  results  ol  a  module  should  be  predictable, 
based  solely  on  the  values  of  its  input  parameters  In  |Stevens74),  under 
the  heading  "Functional  binding",  is  an  interesting  first  cut  methodology 
which  can  be  used  as  an  aid  in  determining  il  a  module  meets  the  first  Cri¬ 
terion.  It  is  baser'  on  evaluating  a  one  sentence  description  of  uV 
module.  Although  the  study  team  uid  not  use  this  technique,  it  appears 
very  usclul,  as  an  aid  fit  building  or  restructuring  a  secure  system. 

The  second  criterion  means  that  the  interface  to  a  module  should  clearly 
rcllcct  iis  implementation.  There  should  be  no  bidden  dependencies  on  or 
assumptions  about  oilier  parts  of  the  system  (e  g.,  arrangement  of  data  :n 
memory,  internal  operation  of  unrelated  modules,  details  of  hardware, 
etc.).  The  module  name  and  its  parameters  should  give  a  fair  guess  about 
Us  function.  As  Britton  and  Pamas  wrote  in  |Britton81], 

"A  sohwure  engineer  should  be  able  to  understand  the  responsi¬ 
bility  ol  a  module  without  understanding  the  module's  internal 
design." 

Hie  third  entenon  is  related  to  the  second  in  that  parameters  passed  to 
and  returned  from  a  module  should  be  clearly  identified  and  have  wcll- 
dclined  consistent  meanings.  Parameters,  formal  and  informal  (c.g.  glo¬ 
bal  variables  ot  environment),  arc  an  important  pan  of  die  connections 
Ik- I  ween  modules  Front  jSicvcns74], 

"Minimizing  connections  between  modules  also  minimizes  die 
paths  along  which  changes  and  errors  tan  propagate  into  odicr 
parts  ol  the  system,  dius  eliminating  disastrous  ’ripple’  effects 
where  changes  in  one  pan  cause  errors  in  another,  necessitating 
additional  changes  elsewhere,  giving  rise  lo  new  errors,  etc." 
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Finally,  32  is  a  popular  target.  The  NCSC  currently  is  experiencing  con¬ 
siderable  demand  for  B2-levcl  developmental  evaluations  of  many  types 
of  systems.  Because  the  B2  assurance  requirements  in  the  TCSEC  am 
vague  and  difficult  to  interpret,  one  of  the  goals  of  the  study  was  to  define 
them  more  clearly  in  support  of  those  evaluations.  Honeywell's  Multics, 
as  the  prototypical  B2  system,  is  considered  to  have  met  the  B2  require¬ 
ments,  but  it  is  just  a  single  sample  point  and  cannot  provide  all  the 
needed  guidance.  As  hoped,  the  UNIX  study  has  provided  additional  gui¬ 
dance  on  how  to  interpret  the  B2  requirements  and  apply  them  to  systems 
under  evaluation. 


REVIEW  OP  THE  B2  REQUIREMENTS 

Having  chosen  the  B2  req  ;rcmcnts  as  the  target  level  for  the  analysis, 
the  study  team's  first  ‘ask  was  to  decide  how  to  assess  compliance  with 
those  requirements.  This  was  done  in  two  stages:  first  understanding  the 
important  distinctions  between  B1  and  B2  then  identifying  the  essence  of 
the  B2  requirements. 

The  Difference  Between  B1  and  B2 

From  reading  the  TCSEC,  it  appears  that  the  chief  distinction  between  B 1 
and  B2  is  one  of  assurances,  and  of  the  comprehensiveness  of  those 
assurances.  The  step  from  B1  to  B2  is  regarded  as  the  single  most 
difficult  transition  in  the  Criteria,  principally  because  of  these  assurance 
requirements. 

The  intent  of  these  assurances  is  to  eliminate  vulnerabilities  to  attack,  real 
or  potential,  that  do  exist  or  that  might  come  itiio  existence  during  the 
entire  life-cycle  of  the  system  —  or,  at  least,  minimize  the  likelihood  of 
such  vulnerabilities.  In  the  early  1970's,  in  [Anderson72]  and  other 
work,  it  was  Observed  that  the  mere  appearance  of  correct  functioning,  or 
even  of  correct  implementation,  was  not  sufficient  to  ensure  that  a  system 
would  operate  securely  under  attack;  nor  was  that  appearance  sufficient  to 
ensure  that  a  oncc-securv.  system  would  remain  secure  after  additional 
development.  From  this  work,  the  overall  goal  of  an  inherently  secure, 
understandable,  and  maintainable  system  emerged:  the  Reference  Moni¬ 
tor. 

When  examined  in  this  light,  die  Reference  Monitor  was  seen  as  the  fun 
damcntal  assurance  of  a  B7.  system.  In  effect,  all  die  other  assurance 
requirements  exist  to  define,  support,  maintain,  and  protect  the  reference 
monitor:  specification,  testing,  maintenance,  and  architecture. 

Furthermore,  aldiough  not  cxplicidy  stated  in  the  TCSFX,  it  became  clear 
that  not  only  must  the  system  meet  the  assurance  requirements,  but  that  it 
must  be  evident  diat  it  docs  so. 


Critical  B2  Requirements 

Five  ot  the  B2  requirements  appear  to  constitute  die  essence  of  the  B2 
assurances.  Although  several  requirements  differ  between  B1  and  B2, 
and  others  are  differently  interpreted  berause  of  die  B2  assurances,  these 
difference^  arc  cidicr  direct  and  obvious  consequences  of  the  B2 
assurances  or  requirements  for  features  that  have  no  direct  relationship  to 
those  assurances.  The  primary  functional  difference,  covered  by  the  Sys¬ 
tem  Architecture  requirement,  is  the  need  to  apply  the  TCB's  security 
policy  ip  all  subjects  and  objects,  rather  than  just  a  chosen  subset. 

The  five  critical  32  requirements  arc: 

•  System  Architecture 

•  Design  Documentation 

•  Design  Specification  and  Verification 

•  Covert  Channel  Analysis 

•  Configuration  Management 


These  five  requirements  are  (at  best)  vaguely  written  and  all  closely 
related.  This  makes  them  difficult  to  consider  individually.  Therefore, 
for  this  study,  they  were  instead  considered  as  a  whole  and  their  contents 
reorganized  into  twelve  areas;  some  of  the  areas  also  incorporate  small 
extracts  from  other  requirements.  Each  of  these  twelve  areas  represents  a 
well-defined  goal  to  follow  when  when  planning  the  development  of  a 
secure  system,  unlike  the  original  five  requirements.  The  appendix  at  die 
end  of  this  paper  contains  the  complete  set  of  extracts  for  each  of  Lhc 
areas,  and  a  brief  summary  of  each. 

The  twelve  assurance  areas  identified  by  the  study  team  arc: 

•  Reference  Monitor  Requirements 

•  TCB  Functional  Requirements 

•  TCB  Isolation  Requirements 

•  Process  Isolation  Requirements 

•  Modularity  Requirements 

•  Least  Privilege  Requirements 

•  Hardware  Requirements 

•  Descriptive  Top-Level  Specification  Requirements 

•  Configuration  Management  Requirements 

•  Covert  Channel  Requirements 

•  Formal  Model  Requirements 

•  Testing  Requirements 


SCOPE  OF  STUDY  TEAM’S  ANALYSIS 

The  object  of  the  team's  analysis  was  the  Trusted  Computing  Base  (TCB) 
software  of  a  UNIX  implcmentadon.  The  generic  UNIX  TCB  consists  of 
two  major  software  components,  the  kernel  and  be  trusted  processes.  An 
aetuul  product  evaluation  of  a  real  UNIX  system  would  also  consider  the 
hardware  and  firmware  components  of  the  TCB,  but  since  the  study  was 
concerned  only  with  lhc  generic  UNIX  software  architecture,  diose  com¬ 
ponents  were  not  considered.  The  UNIX  TCB  software  is  wntten  pri¬ 
marily  in  lhc  C  programming  language,  although  Uicre  is  some  amount  of 
implementation-dependent  assembler  code  in  most  UNIX  systems. 

The  first  software  component  is  the  kernel,  which  runs  in  the  hardware’s 
privileged  slate.  Its  services  are  requested  by  “system  calls",  which 
switch  the  process  to  run  in  the  privileged  state  and  transfer  to  lhc  kernel 
code,  Its  data  structures  are  shared  by  all  processes,  but  accessible  only 
when  the  process  is  running  in  the  kernel.  The  kernel  implements  most 
of  the  basic  operating  system  functions  that  control  sharing  of  and  access 
to  resources. 

The  second  sofiwarc  component  is  the  set  of  trusted  processes.  The 
trusted  processes  arc  simply  all  those  UNIX  processes  which  run  with  a 
distinguished  (privileged)  user  ID.  One  such  user  ID  is  zero,  the  root  user 
ID,  or  the  "super  user",  which  can  execute  all  privileged  system  calls 
and  is  not  subject  to  access  control.  Olher  distinguished  user  IDs  arc  used 
to  grant  access  to  certain  shared  TCB  files  and  dircc'orics,  such  as  the 
primer  spooler’s  directory  (though  in  standard  UNIX,  most  such  access  is 
granted  only  to  root  and  not  more  tightly  controlled).  All  other  processes 
(belonging  to  unprivileged  users)  arc  outside  the  TCB,  although  an 
unprivileged  process  may  dynamically  invoke  a  privileged  (trusted)  pro¬ 
cess  to  request  some  service  from  the  TCB. 

When  considering  the  actual  UNIX  implemcrualion,  the  study  ream 
quickly  realized  that  the  primary  question  was  not  whether  die  system 
included  a  reference  monitor,  whether  it  isolated  the  TCB,  whether  it  was 
composed  cf  well-defined  modules,  and  so  forth,  but  rather,  how  to  make 
that  determination  It  was  simply  not  evident  that  any  of  these  require¬ 
ments  were  met,  and  difficult  to  see  bow  one  could  make  that  determina¬ 
tion,  or  ensure  that  the  requirements  wouid  still  be  met  after  maintenance 
in  Die  future.  Although  a  UNIX  expert  might  argue  that  all  these  archi¬ 
tecture  requirements  arc  met,  had  one  but  the  wit  to  see  it,  this  merely 
reinforces  the  conclusion  that  the  system's  architecture  is  not  manifest  in 
its  implementation,  but  instead  exists  primarily  in  die  minds  of  its 
designer;. 
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Good  modularity  minimizes  coupling.  Coupling  [Stc.vcr.s74]  is: 

"a  measure  of  the  strength  of  association  established  by  a  con¬ 
nection  from  one  module  to  another . . .  Coupling  increases  with 
increasing  complexity  or  obscurity  of  interface." 

extensive  use  of  global  variables  causes  every  module  sharing  them  to  be 
coupled  to  every  other  such  module  "without  regard  to  their  functional 
relationship  or  its  absence. "]Stevcns74]  Belady  and  Lchmtn[Rclady71] 
observed  that: 

“a  well-structured  system,  one  in  which  communication  is  via 
passed  parameters  through  defined  interfaces,  is  likely  to  be 
more  gnowablc  and  require  less  cflon  to  maintain  th  n  one  mak¬ 
ing  extensive  use  of  global  or  shared  variables.” 

Britton  and  Pamas  [ BriltonS  1  ]  also  expressed  their  views  of  global  vari¬ 
ables.  This  definition  is  much  closer  to  the  original  working  definition, 
but  is  also  at  a  lower  level  of  abstraction  than  simply  considering  the 
entire  TCB  as  a  single  module. 

“Every  data  structure  is  private  to  one  module;  it  may  be  directly 
accessed  by  one  or  more  programs  within  the  module  but  not  by 
programs  outside  the  module." 

Of  course,  an  operating  system  may  require  seme  use  of  global  variables. 
But  as  |Sievens74]  observes, 

“it  is  possible  to  minimize  the  disadvantages  of  common 
environments  by  limiting  access  to  the  smallest  possible  subset 
of  modules.” 

The  fourth  criterion  means  that  the  function  performed  by  a  module 
should  always  be  performed  by  calling  that  module,  rather  than  being 
implemented  in  multiple  locations.  Note  that  this  docs  not  prcciudc 
iniinc  macro  expansions  of  code  inserted  from  include  tiles;  rather,  the 
goal  is  simply  to  ensure  that  the  actual  piogrammcr-crca'.cd  definition  of 
a  function  appears  in  only  one  place. 

The  desire  that  multiple  uses  of  a  function  share  one  definition  should  not 
be  taken  to  mean  that  a  function  required  only  once  ought  not  to  be 
defined  independently.  Rather,  wherever  possible,  independent  functions 
snould  be  implemented  as  separate  modules,  even  if  they  arc  only  used 
once.  This  criterion,  along  with  the  use  of  consistent  programming  style 
among  developers,  should  result  in  a  similar  control  structure  and  call 
sequence  in  modules  performing  similar  functions. 


UNIX  System  Modularity 

The  study  team's  examination  of  the  UNIX  TCB  covered  approximately 
60  percent  of  the  kernel  and  35  percent  of  die  trusted  (privileged) 
processes.  For  every  function  examined  in  the  TCB,  the  team  produced 
an  analysis  report  describing  the  function’s  apparent  contract  (as  best  as 
could  tic  determined  from  reading  the  code),  its  parameters,  its  use  of  glo¬ 
bal  variables,  its  calls  to  other  functions,  and  its  conformance  with  the 
definition  of  modularity  given  above. 

At  higher  levels  of  abstraction,  the  team  looked  for  object  or  resource 
managers  acting  as  the  interface  to  TCB  data  structures  wherever  die 
packaging  and  structure  su|iported  such  analysis.  Although  packages  (C- 
languagc  source  files)  also  represent  a  readily  identifiable  group  of  code, 
die  generic  UNIX  packaging  of  functions  into  source  files  is  haphazard 
and  uninformative  (Berkeley  UNIX  has  made  some  improvement  in  this 
area).  The  conclusion,  however,  was  that  while  source  tile  packages 
cculd  form  die  basis  for  a  more  abstract  view-  of  kernel  modularity,  most 
of  the  basic  UNIX  TCB  still  would  not  exhibit  a  high-level  modularity 
even  if  entirely  reorganized  and  repackaged.  The  lack  of  clear  divisions 
between  major  subsystems  appears  to  be  an  inherent  system  characteris¬ 
tic,  not  merely  an  artifact  of  poor  packaging.  There  were  some  notable 
exceptions  to  this  observation,  such  as  die  file  system's  buffer  manager 
|BachK6J. 


After  this  detailed  examination  of  the  UNIX  TCB,  the  study  team  con¬ 
cluded  that  generic  UNIX  docs  not  meet  the  B2  requirements  for  modu¬ 
larity  (in  addition  to  problems  with  some  oilier  D2  requirements,  dis¬ 
cussed  below).  This  conclusion  was  based  on  die  following  observations: 

•  The  kernel  includes  pervasive  misuse  of  global  variables.  It 
modifies  supposedly  constant  values  to  lake  advantage  of  their 
side-effects,  it  sliarcs  global  variables  among  wholly  unrelated 
modules,  it  uses  global  variables  in  many  eases  where  formal 
parameters  should  be  used,  and  it  uses  global  variables  for  tem¬ 
porary  storage  of  purely  local  information  This  is  the  single  largest 
problem  area,  and  the  first  one  that  should  be  corrected  in  any  B2 
UNIX  implementation.  A  prime  example  of  this  was  die  global 
temporary  values  used  by  namei  (the  multi-purpose  pathname  reso¬ 
lution  function).  Global  variables,  as  such,  are  much  less  of  a  prob¬ 
lem  for  the  trusted  processes,  since  they  primarily  share  data  in  files. 

•  The  UNIX  TCB  contaias  numerous  examples  of  duplicated 
functions —  very  similar,  or  in  some  eases  identical—  functioas. 
Thsc  duplicated  functions  were  sometimes  syntactically  identical, 
sometimes  subtly  different.  These  examples  were  often  the  result  of 
using  in-line,  operations  rather  than  function  calls  to  perform  well- 
defined  operations,  such  as  searching  for  entries  in  the  mount  and 
proc  tables.  This  was  also  a  problem  in  the  trusted  processes,  where 
a  group  of  related  busted  processes  (such  as  components  of  the 
printer  spooler)  contained  wholly  duplicated  code,  rather  than  calls 
to  library  routines. 

•  The  packaging  of  the  kernel  is  very  poor.  Functions  are  scattered 
among  different  source  files  even  though  their  purposes  are  closely 
related.  This  in  itself  does  not  prevent  high-level  modularity,  but  if 
not  corrected  would  make  the  modularity  invisible  even  if  theoreti¬ 
cally  present.  For  example,  functions  for  performing  directory 
management  are  scattered  among  several  different  source  flies,  as 
arc  the  funciions  which  perform  access  checks.  Packaging  of  Ihc 
trusted  processes  is  much  better,  since  each  trusted  process  must 
have  its  own  source  file. 

•  Related  to  the  above  problem  is  the  organization  of  external  data 
structure  definitions  (“.h”)  files.  Practically  every  function  in  the 
kernel  includes  all  the  major  “.h"  files;  determining  whether  a 
function  actually  references  one  of  those  data  structures  is  therefore 
very  difficult.  This  is  an  artifact  of  the  C-languagc  data  definitions, 
but  one  which  could  be  avoided  by  belter  structure  and  some  help 
from  the  compilers.  Here  again,  what  data  structures  arc  actually 
referenced  is  not  as  important  as  ensuring  that  those  patterns  arc 
readily  apparent.  Another  asjxrct  of  this  problem  is  ihat  it  is  very 
difficult  to  determine  (from  name  or  usage)  what  modules  "own”  a 
particular  structure  element  (or  even  the  whole  structure).  This  was 
much  less  of  a  problem  for  the  trusted  processes,  since  they  share 
little  (if  any)  data  except  by  common  file  formats. 

•  Many  TCB  functions  arc  complex  and  ill-dclincd.  Rather  than 
calling  on  another  appropriate  function  to  manipulate  a  data  struc¬ 
ture,  the  manipulations  are  done  directly,  with  no  assurance  that 
they  conform  to  the  rules  of  Ihc  data  structure’s  managing  functions. 
Other  functions'  contracts  arc  ill-defir.ed,  sometimes  reluming 
values  or  setting  global  values  and  other  times  not.  Examples  of 
this  include  the  multi-purpose  contract  of  namei  and  the  complex 
series  of  operations  performed  by  the  exec  system  call  or  the  login 
misted  process. 


ADDITIONAL  ASSURANCE  REQUIREMENTS 

Although  UNIX  was  not  specifically  assessed  in  the  assurance  areas  other 
than  modularity  (because  of  their  implementation-dependent  nature),  the 
team  concluded  that  UNIX-based  systems  were  likely  to  require  consider¬ 
able  work  in  other  areas  before  approaching  compliance  with  the  B2 
requirements.  These  are  strictly  assurance  requirements,  not  functional 
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requirements  for  features  such  as  auditing  and  mandatory  access  control. 
They  represent  additional  work  required  beyond  simply  implementing  the 
B 2  security  features.  Work  is  needed  in  the  following  areas: 

•  Reference  Monitor  —  The  existing  UNIX  reference  monitor  is  dis¬ 
tributed  among  many  programs,  some  in  the  kernel  and  many  others 
outside.  While  a  single  “reference  monitor"  controlling  all  forms  of 
access  to  all  types  of  objects  may  be  impractical,  the  UNIX  "refer¬ 
ence  monitors"  arc  far  more  distributed  than  necessary.  Access 
checks  arc  made  in-line  throughout  tire  TCB  rather  than  by  calls  to 
any  common  access  policy  routine. 

•  Effective  Use  of  Protection  Hardware  —  The  base  UNIX  system  is 
inherently  a  two-state  system.  The  original  implementation,  plus 
years  of  portability,  have  left  UNIX  strongly  mired  in  a  hardware 
world  with  two  protection  states  and  an  unsophisticated  addressing 
architecture.  Considerable  work  appears  necessary  to  build  a 
UNIX-based  system  that  can  take  proper  advantage  of  the  more 
sophisticated  hardware  available  in  today's  systems. 

•  Least  Privilege  —  Standard  UNIX  syrtems  completely  fail  the  least 
privilege  requirement.  Within  the  TCB,  die  only  mechanism  for  res¬ 
tricting  the  privilege  of  TCB  components  is  process  isolation,  and 
that  only  affects  TCB  components  outside  the  kernel  (the  trusted 
processes).  Within  the  kernel,  all  programs  are  equally  privileged, 
and,  since  all  Dusted  processes  in  a  standard  UNIX  run  as  root,  they 
are  all  also  equally  privileged.  At  the  user  and  administrator  inter¬ 
face  level  only  vestigial  forms  of  least  privilege  exist:  an  adminis¬ 
trative  user  possesses  all  privileges,  by  virtue  of  running  as  root.  To 
satisfy  the  B2  requirements,  some  form  of  least  privilege  is  required 
for  trusted  programs,  and  a  mechanism  is  required  to  separate 
administrator  and  operator  roles. 

~  Descriptive  Top-Lcvc!  Specification  (DTLS)  —  The  UNIX  DTLS 
takes  die  lonn  of  manual  pages  for  system  calls  and  administrative 
commands.  Although  the  cxisdng  standard  UNIX  documentation  is 
a  good  start,  it  is  somewhat  incomplete  for  system  calls  and  seri¬ 
ously  incomplete  for  administrative  interfaces.  For  a  secure  UNIX 
system,  new  documentation  must  be  provided  to  include  new 
security-related  system  calls  and  administrator  interfaces,  but  the 
existing  documentation  must  be  improved  as  well  lo  give  more 
complete  functional  descriptions,  lists  of  effects  and  error  returns, 
etc. 


ADVICE  FOR  B2  SYSTEM  BUILDERS 

The  study  team’s  main  conclusion  —  and  diis  is  just  restating  what  has 
been  said  many  times  before  —  is  that  building  a  B2  system  is  a  hard  job. 
It  is  certainly  possible,  but  remember: 

Bringing  an  existing  system  to  the  B2  ievel  is  likely  to 
be  at  least  as  difficult  as  building  a  brand  new  system. 

It  is  not  clear  whether  it  is  possible  to  retrofit  the  B2  assurances  into  a 
generic  UNIX  system.  Doing  so  appears  lo  require  major  reorganization 
of  code  and  data  structures,  if  not  outright  rcimplcmcntation  of  many 
parts  of  the  TCB.  This  is  even  more  true  for  non-UNIX-based  opcraling 
systems:  UNIX  does  appear  to  be  better  structured  internally  than  most  of 
today's  existing  systems.  The  UNIX  system  interface,  being  relatively 
simple,  is  also  much  better  suited  to  a  highly  secure  system  than  the  com¬ 
plex  interfaces  of  some  other  operating  systems. 

One  of  the  goals  of  this  study  was  to  dctinc  the  architecture  requirement 
for  a  B2  system  in  a  language  that  vendors  and  evaluators  could  under¬ 
stand.  Iltal  goal  was  not  achieved:  no  cookbook-like  set  of  guidelines  for 
building  a  B2  system  is  available.  As  with  most  software  engineering 
topics,  precise  measures  simply  do  not  exist.  As  Supreme  Court  Justice 
l’olter  Stewart  once  said,  "I  may  not  be  able  to  define  obscenity,  but  1 
know  it  when  I  sec  it.”  Tlx;  same  applies  to  B2  architecture. 


This  study  did,  however,  produce  some  good  analysis  techniques  for  gen¬ 
erating  the  necessary  sui<porting  evidence  and  for  guiding  system 
development  in  the  right  directions  The  recommended  techniques 
include: 

»  Eliminate  global  variables  whenever  possible.  When  they  must  be 
used,  assign  them  precisely  defined  semantics.  Enforce  those 
semantics,  perhaps  by  coding  standards  and  code  review  guidelines, 
perhaps  by  automated  source  or  cross-reference  analysis,  perhaps  by 
using  segmentation  hardware  to  enforce  the  semantics  at  run-time, 
too.  All  of  this  adds  greatly  to  internal  assurance,  and  proper  treat¬ 
ment  of  globals  also  seems  to  encourage  other  practices  for  good 
modularity. 

«  Use  packaging  to  illustrate  levels  of  abstraction,  not  to  obscure 
them.  Make  certain  that  the  system’s  structure  and  modularity  arc 
evident,  and  consistent,  throughout. 

•  Develop  and  follow,  throughout  the  system,  naming  conventions 
that  make  the  purpose  of  functions  and  variables  readily  apparent. 
Remember  that  a  naming  convention  that  isn’t  universally  followed 
is  in  many  ways  worse  than  none  al  all.  Pay  as  careful  attention  to 
this  aspect  of  the  design  as  to  any  other. 

•  Use  the  hardware  to  its  best  advantage.  If  the  system  docs  not  use  a 
hardware  protection  feature,  it  is  probably  not  as  secure  as  it  ought 
to  he.  These  features  are  supposed  lo  reduce  the  cost  of  security,  not 
increase  it. 

•  Write  everything  down.  Document  the  coding  practices,  the  packag¬ 
ing  rules,  die  data  structure  design  principles,  the  module  hierarchy. 
Make  each  module's  contract  explicit,  each  data  structure's  purpose 
clear,  and  honor  those  contracts  when  making  changes.  One  of  the 
biggest  problems  with  analyzing  UNIX  is  dial  none  of  those  hidden 
assumptions  were  documented.  While  the  original  implementor  ol 
a  function  may  have  known  just  what  it  was  supposed  to  do  and 
why,  the  programmers  who  modified  it  afterward  usually  lacked 
access  to  that  knowledge  —  as  did  the  study  team. 

•  Treat  the  assurance  requirements  for  B2  a’  i  whole.  As  the  study 
team  learned  at  the  very  beginning,  assessing  compliance  with  just 
one  of  the  assurance  requirements  is  pointless,  because  the  security 
of  the  system  depends  intimately  on  all  of  them.  The  live  critical 
assurance  requirements  are  all  equally  important,  and  slighting  any 
one  of  them  will  lead  lo  serious  problems. 


APPENDIX:  SUMMARY  OF  B2  REQUIREMENTS 

This  section  divides  the  B2  requirements  into  12  logical  groups,  each  of 
which  consists  of  scn'cnccs  or  extracts  from  some  of  die  B2  TCSF.C 
)DoD85|  requirements  (some  extracts  may  appear  more  than  once,  in  dif¬ 
ferent  groups).  Each  group  begins  wtdt  the  relevant  scnlcncc(s)  quoted 
from  die  various  rcquiremcnt(s),  and  follows  with  a  brief  explanation  ol 
the  grouping’s  intent. 

Each  extract  is  identified  with  the  requirement  from  which  it  comes,  by 
one  of  the  following  abbreviations  (in  brackets)  at  die  end  of  die  extract 
The  first  five  requirements  are  die  critical  requirements  for  architectural 
assurance,  and  are  quoted  in  dicir  entirety  among  the  12  groupings.  The 
other  six  requirements  do  not  s[iccifica!Iy  require  architectural  assurances, 


but  imply  certain  architectural  characteristics. 

SA 

System  Architecture 

DD 

Design  Document alien 

DS&V 

Design  Specification  and  Verification 

CM 

Configuration  Management 

CCA 

Covert  Channel  Analysis 

AUDIT 

Audit 

LABELS 

Labels 

MAC 

Mandatory  Access  Control 

TFM 

Trusted  Facility  Manual 

ST 

Security  Testing 

TD 

Test  Documentation 

The  other  sixteen  B2  requirements  have  no  specific  hearing  on  architec¬ 
tural  assurances,  and  arc  not  considered  in  this  analysis.  Except  for  audit, 
labels,  and  mandatory  access  control  (which  differ  at  B2  in  requiring 
comprehensive  coverage  of  all  TCB -provided  objects),  the  remaining  six¬ 
teen  include  all  the  feature  requirements,  the  system  integrity  require¬ 
ment,  and  the  security  features  user’s  guide  requirement.  All  but  four  of 
these  other  requirements  arc  unchanged  in  wording  from  the  equivalent  at 
Bl. 


REFERENCE  MONITOR  REQUIREMENTS 

“Documentation  shall  describe  how  the  TCB  implements  the 
reference  monitor  concept  and  give  an  explanation  why  it  is 
tamper  resistant,  cannot  be  bypassed,  and  is  correctly 
implemented."  1DD1 

“The  TCB  modules  that  contain  die  reference  validation  mechan¬ 
ism  shall  be  identified.”  ITFMJ 

“The  TCB  shall  enforce  a  mandatory  access  control  policy  over 
all  resources  (i.c.,  subjects,  storage  objects,  and  I/O  devices) 
that  are  dircedy  or  indireedy  accessible  to  the  TCB.’’  (MAC) 

“The  following  requirements  shall  hold  for  all  accesses  between 
all  subjects  external  to  the  TCB  and  all  objects  directly  or 
indireedy  accessible  by  these  subjects: ..."  IMACI 

"Sensitivity  labels  associated  with  each  ADF  system  icsuuicc 
(c.g.,  subject,  storage  object,  ROM)  that  is  directly  or  indireedy 
accessible  by  subjects  external  to  the  TCB  shall  be  maintained 
by  the  TCB."  [LABELS] 

These  requirements  address  the  implementation  of  the  Reference  Monitor 
[Anderson72]  principle.  The  first  two  extracts  quoted  above  address  the 
reference  monitor  principles;  the  laucr  three  address  the  completeness  of 
its  coverage.  The  Reference  Validation  Mechanism  is  an  implementation 
(of  a  reference  monitor)  "that  validates  each  reference  to  data  or  pro¬ 
grams  by  any  user  (program)  against  a  list  of  authorized  types  of  refer¬ 
ence  for  that  user."  The  Reference  Validation  Mechanism  must  satisfy 
the  following  requirements: 

1)  The  Reference  Validai  on  Mechanism  must  be  tamper  resistant 

2)  The  Reference  Validation  Mechanism  must  always  be  invoked 

3)  The  Reference  Validation  Mechanism  must  be  small  enough  to  be 
subject  to  analysis  and  tests,  the  completeness  of  which  can  be 
assured. 

Although  not  cxplicidy  staled,  it  is  clear  from  these  requirements  lhai  the 
Trusted  Computing  Base  in  a  B2  system  may  contain  more  than  just  the 
reference  monitor.  It  may  also  contain  other  components  dial  are  not 
dircedy  involved  with  mediation  of  user  access  lo  data,  tut  which 
nonetheless  must  function  correctly  for  the  TCB  to  satisfy  (lie  oilier 
requirements.  To  provide  the  necessary  assurance,  however,  all  com¬ 
ponents  of  the  TCB  must  be  guaranteed  not  to  interfere  with  operation  of 
the  reference  monitor  proper,  and  this  means  that  the  entire  TCB  must  be 
sufficiently  wcU-stiuclurcd  and  well-defined  to  be  analyzed  and  tested. 

There  is  no  requirement  for  a  single  identifiable  hardware  or  software 
component  that  is  the  reference  monitor.  Rather,  the  reference  monitor  is 
the  collection  of  reference  validation  mechanisms  used  for  different  types 
of  objects  This  includes  bodt  hardware  validation  of  direct  access  to 
memory  and  software  validation  of  access  lo  TCB-dcfincd  objects  by 
invoking  the  TCB.  Higher  levels  of  abstraction  in  die  reference  monitor 
can  and  should  be  built  lo  depend  on  lower  levels.  Eor  instance,  TCB 
colls  to  manipulate  higher-level  (software)  objects  should  be  able  to  rely 


on  die  lower-level  hardware  mechanisms  to  validate  accesses  to  user 
memory  (containing  parameters,  for  instance). 


TCB  FUNCTIONAL  REQUIREMENTS 

“Documentation  shall  be  available  that  provides  a  description  of 
the  manufacturer's  philosophy  of  protection  and  an  explanation 
of  how  this  philosophy  is  translated  into  the  TCB."  |DD] 

This  requirement  addresses  the  high-level  structure  of  the  TCB  and  the 
TCB  interface;  in  effect,  how  die  mechanisms  required  by  the  "feature" 
requirements  are  collected  into  a  TCB  that  implements  diem. 

The  "philosophy  of  protection”  must  map  to  the  other  Criteria  require¬ 
ments.  but  there  arc  many  possible  mappings.  It  must  cover  both  the 
security  features  and  the  mechanisms  for  TCB  protection  and  isolation. 

ISOLATION  REQUIREMENTS 

rhe  TCB  shall  maintain  a  domain  for  its  own  execution  that 
protects  it  from  external  interference  or  tanit>;ring  (e.g.,  by 
modification  of  its  code  or  data  structures)."  ISA) 

"...  all  elements  of  the  TCB  ishall  be]  identified.”  (Sa) 

This  requires  that  the  TCB  be  isolated  in  at  least  one  domain  inaccessible 
to  users.  It  does  no!  require  precisely  one  TCB  domain;  rather,  the  isola¬ 
tion  of  TCB  components  into  individual  protection  domains  is  a  decision 
made  to  satisfy  the  requirements  for  structure  and  independence  of  TCB 
mduics. 

The  1 CB  isolation  may  be  provided  by1  different  mechanisms  for  dif¬ 
ferent  TCB  domains.  How  this  relates  to  use  of  hardware  is  discussed 
below  (see  Hardware  Requirements).  Since  the  TCB  consists  of  all  code 
with  the  potential  to  violate  the  system  security  policy  (that  is,  both  code 
that  is  intentionally  granted  the  pnvilegc  and  code  that  inherits  it  from  the 
invoking  environment),  all  such  code  must  be  isolated  from  tampering.  If 
a  variety  of  mechanisms  is  used  to  provide  this  isolation  (for  example, 
hardware  privilege,  process  privileges,  access  to  special  files  and/or  dev¬ 
ices,  special  user  identity),  the  TCB  boundary  is  much  more  difficult  to 
analyze  (or  even  describe). 

PROCESS  ISOLATION  REQUIREMENTS 

“The  TCB  shall  maintain  process  isolation  through  the  provision 
of  distinct  address  spaces  under  its  |ihc  TCB’s]  control."  ISA! 

The  term  "address  space"  here  refers  not  only  to  the  addressable  main 
storage  accessible  to  a  process,  but  also  to  the  addressability  of  other 
TCB-providcd  resources  (objects).  This  docs  not  require  that  the  system 
function  without  ever  sharing  objects  between  processes,  but  simply  that 
the  TCB’s  mediation  and  control  mechanisms  always  come  in  to  play  for 
all  objects;  that  is,  that  ail  sharing  must  be  intentional. 

MODULARITY  REQUIREMENTS 

"The  TCB  shall  be  internally  structured  into  well-defined  largely 
independent  modules  ”  ISA] 

“The  interfaces  between  the  TCB  modules  stiall  be 
described.”  |DD) 

“During  development  and  maintenance  of  the  TCB,  a 
configuration  management  system  shall  be  in  place  that  main¬ 
tains  control  of  changes  to . . .,  other  design  data,  implementa¬ 
tion  documentation,  source  code. . .”  [CM] 

This  is  a  complex  topic,  and  is  addressed  only  vaguely  by  the  TCSEC 
requirements.  The  requirements  arc  deliberately  vague,  to  avoid  dictating 
implementation  technique,  but  the  basic  emphasis  is  ope  of  good  struc- 
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turc  and  program  design.  It  is  not  the  intent  of  the  B2  requirements  to 
demand  that  the  entire  TCB  follow  a  uniform  standard  of  perfection,  but 
rather  to  ensure  that  the  TCB  is  largely  in  compliance  with  the  require¬ 
ments,  and  that  there  arc  no  major  violations  of  modularity  and  indepen¬ 
dence. 

The  configuration  management  requirements  for  maintenance  of  docu¬ 
mentation  are  particularly  important  to  modularity.  Design  documenta¬ 
tion  must  be  kept  up  to  date  with  the  code,  and  therefore  must  be  updated 
whenever  the  code  is  updated.  To  make  this  updating  easier,  externa! 
design  documentation  snould  provide  a  view  of  tire  code  dial  focuses  on 
the  overall  purpose  of  modules  and  the  interactions  between  modules, 
rather  than  the  details  of  internal  structure.  When  arranged  (his  way, 
external  documentation  sltould  be  supplemented  by  internal  documenta¬ 
tion  (e.g.,  comments)  in  the  modules  themselves  to  cover  internal  details 
(though  still  at  a  higher  level  of  abstraction  than  the  code  itself) 

It  is  not  sufficient  simply  to  asset!  Ihat  "the  aide  is  the  documentation.” 


LEAST  PRIVILEGE  REQUIREMENTS 

“The  TCB  modules  shall  be  designed  such  that  the  principle  of 
least  privilege  is  enforced."  [SAI 

"Documentation  shall  describe  how  die  TCB  is  structured  ...  to 
enforce  least  privilege.’’  (DD1 

These  requirements  refer  to  the  principle  of  least  privilege  within  the 
TCB;  that  is,  the  means  by  which  one  is  assured  that  a  pan  of  die  TCB 
cannot  exercise  privileges  beyond  those  required  for  its  specific  function. 
It  is  important  that  some  specific  mechanism  be  used  to  provide  this 
assurance.  It  is  not  sufficient  simply  to  assert  that  no  part  of  die  TCB 
uses  its  privileges  inappropriately.  It  must  also  be  possible  10  demon¬ 
strate  the  validity  of  the  assertion  by  analyzing  the  mechanism  diat 
enforces  it.  Enforcement  of  the  least-privilege  principle  is  an  important 
reason  to  use  multiple  domains  for  TCB  execution. 


HARDWARE  REQUIREMENTS 

"It  [the  TCB]  shall  make  cffcciivc  use  of  available  hardware  to 
separate  those  elements  |of  die  TCB]  dial  arc  proiection-criueal 
from  those  that  are  not."  ISA] 

“Features  in  hardware,  such  as  segmentation,  shall  be  used  to 
support  logically  distinct  storage  objects  with  separate  attributes 
(namely:  readable,  writcablc)."  ISA] 

This  is  another  appearance  of  die  distinction  between  more  and  less  criti 
cal  components  of  tbc  TCB;  clearly,  those  components  die'  make  up  die 
reference  monitor  arc  more  protection-critical,  but  there  may  be  other 
protccUon-criucal  components  as  well. 

Using  hardware  mechanisms  to  separate  TCB  components  is  one  pan  of 
implcmcntating  the  least  privilege  principle.  Not  all  TCB  "domains" 
need  he  established  by  the  same  hardware  mechanism.  For  example,  part 
of  a  TCB  might  be  defined  as  the  code  that  executes  with  hardware- 
defined  privilege  (the  “kernel,"  usually),  and  other  parts  of  die  TCB 
might  be  otherwise  ordinary  processes  that  arc  distinguished  only  by 
software-defined  privilege  (the  "trusted  processes").  Even  dio.igh  the 
process  isolation  used  for  the  latter  part  of  the  TCB  is  not  a  hardware  pro 
lection  mechanism  as  such,  it  still  represents  use  of  hardware  features  to 
isolate  parts  of  die  TCB. 

DESCRIPTIVE  TOP-LEVEL  SPECIFICATION  REQUIREMENTS 

Hie  user  interface  to  the  TCB  shall  be  completely  defined  and 
all  elements  of  the  TCB  identified."  [SA] 


“A  descriptive  top-level  specification  (DTLS)  of  the  TCB  shall 
be  maintained  dial  completely  and  accurately  describes  the  TCB 
in  terms  of  exceptions,  error  messages,  and  effects."  (DS&  V] 

"It  | the  DTLS)  shall  be  shown  to  be  an  accurate  description  ol 
the  TCB  interface.”  IDS&V] 

“The  desenptive  top-level  specification  (DTLS)  shall  be  shown 
to  he  an  accurate  description  of  the  TCB  interface."  |DD] 

“Testing  shall  demonstrate  that  die  TCB  is  consistent  widi  die 
descriptive  top-level  specification."  1ST] 

"The  procedures  for  examining  and  maintaining  the  audit  files  as 
well  as  detailed  audit  record  structure  for  each  type  of  audit 
event  shall  be  given."  ITFM] 

“During  development  and  maintenance  of  the  TCB,  a 
configuration  management  system  shall  be  in  place  that  main¬ 
tains  control  of  changes  to  ihe  descriptive  top-level 
specification, ..."  ICMI 

The  DTLS  deals  with  the  interface  presented  by  the  TCB  to  ordinary 
users,  operators,  and  administrators.  It  must  be  a  complete  description  of 
the  interface  (or  interfaces),  and  must  include  all  ways  in  which  a  user 
can  interact  widt  the  TCB.  This  may  actually  be  easier  to  define  than  the 
TCB  boundary  (see  TCB  Isolation,  above),  since  il  deals  only  with 
corrccl,  expected  TCB  operations,  rather  dtan  all  potential  actions.  The 
DTLS  need  not  be  packaged  as  a  single  document,  but  all  its  components 
should  be  readily  identifiable. 

One  of  the  "cffccls"  of  the  TCB  interface  is  the  generation  of  audit  mes¬ 
sages.  This  is  part  of  the  DTLS,  and  as  such  must  be  documented  ar.d 
tested;  in  this  ease,  however,  it  is  acceptable  to  consider  dial  portion  of 
the  TFM  documentation  as  also  a  part  of  the  DTLS  (or  vice-versa). 


CONFIGURATION  MANAGEMENT  REQUIREMENTS 

“During  development  and  maintenance  of  the  TCB,  a 
configuration  management  system  shall  be  in  place  that  main¬ 
tains  control  of  changes  to  the  descriptive  top-level 
specification,  other  design  data,  implementation  documentation, 
source  code,  the  running  version  of  die  object  code,  and  lest 
fixtures  and  ciocumcmauon.”  ICMI 

"The  configuration  management  system  shall  assure  a  consislent 
mapping  among  all  documentation  anil  code  associated  with  die 
current  vet  sion  of  the  TCB."  |CM) 

"Tools  shall  be  provided  for  generation  of  a  new  version  of  die 
TCB  from  source  code."  ICMI 

"Also  available  shall  be  tools  for  comparing  a  newly  generated 
version  with  die  previous  TCB  version  in  order  to  ascertain  that 
only  die  intended  changes  have  been  made  in  the  code  that  will 
actually  be  used  as  the  new  version  of  the  TCB."  1CM] 

"The  procedures  for  secure  gcncralion  of  a  new  version  of  the 
TCB  from  source  after  modification  of  any  modules  in  the  TCB 
shall  be  described."  I1TM1 

The  object  of  Ihe  configuration  management  requirements  is  the  continual 
assurance  ol  corrccl  system  design  and  implementation.  Although  diese 
ate  not  directly  related  to  system  architecture  per  sc,  they  do  have  strong 
bearing  on  the  maimancncc  of  that  architecture  and  the  preservation  of  its 
■‘inherent"  security  properties. 

Configuration  management  requires  both  a  mechanism  for  maintaining 
the  TCB  and  all  TCB-rclated  material  (first  exempt)  and  a  set  of  pro 
ccdures  (second  exempt)  for  guaranteeing  proper  correspondence  among 
these  materials.  Tools  and  procedures  for  modification  and  validation  of 
the  TCB  arc  required.  It  is  not  necessary  for  die  TCB  to  be  customcr- 
modiliablc,  though  appropriate  tools  must  be  available  if  it  is.  It  is  satis¬ 
factory  for  the  "procedure”  for  securely  generating  a  new  TCB  to  be 
purchasing  anodter  version  from  the  manufacturer. 
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COVERT  CHANNEL  REQUIREMENTS 

“The  system  developer  shall  conduct  a  thorough  search  for 
covert  storage  channels  and  make  a  determination  (either  by 
actual  measurement  or  by  engineering  estimation)  of  the  max¬ 
imum  bandwidth  of  each  identified  channel."  [CCAI 

“The  TCB  shall  be  able  to  audit  the  identified  events  that  may  be 
used  in  the  exploitation  of  covert  storage  channels."  I  AUDIT) 

“All  auditable  events  that  may  be  e  d  in  the  exploitation  of 
known  covert  storage  channels  shall  u  identified.' '  (DD1 

“The  bandwidths  of  known  covert  storage  channels,  the  use  of 
which  is  not  delectable  by  the  auditing  mechanism,  shall  be 
provided.”  (DD1 

“This  [design]  documentation  shall  also  present  the  results  of  the 
covert  channels  analysis  and  the  tradeoffs  involved  in  restricting 
the  channels."  IDD] 

“It  [the  test  documentation]  shall  include  results  of  testing  the 
effectiveness  of  the  methods  used  to  reduce  covert  channel 
bandwidths.”  [TD1 

The  covert  channel  requirements  address  the  identification,  suppression, 
and  documentation  of  all  coven  channels.  In  orderto  perform  an  analysis 
at  all,  however,  it  is  necessary  for  the  TCB  to  be  sufficiently  well- 
structured  that  all  shared  resources  can  be  identified  and  considered  as 
potential  information  flow  paths. 

FORMAL  MODEL  REQUIREMENTS 

“A  formal  model  of  the  security  policy  supported  by  the  TCB 
shall  be  maintained  over  the  life  cycle  of  the  ADP  system  that  is 
proven  consistent  with  its  axioms."  [DS&'v'j 

“A  formal  description  of  the  security  model  enforced  by  the  TCB 
shall  be  available  and  proven  that  it  is  sufficient  to  enforce  the 
security  policy."  (DD1 

"The  specific  TCB  protection  mechanisms  shall  be  identified  and 
an  explanation  given  to  show  that  they  satisfy  the 
model."  [DD] 

"During  development  and  maintenance  of  the  TCB,  a 
configuration  management  system  shall  be  in  place  'hat  main¬ 
tains  control  of  changes  to  the  [DTLS],  other  design 
data,...”  ICM] 

This  requires  first  that  a  formal  security  model  (such  as  Bell  and 
l.a  Padula)  be  identified  and  accepted.  The  model  must  then  be  inter¬ 
preted,  identifying  all  lire  subjects,  objects,  operations,  permissions,  and 
mechanisms  in  the  TCB,  and  showing  how  they  correspond  to  the  terms 
of  the  model.  Unlike  the  model  itself,  which  (being  abstract)  will  usually 
remain  unchanged  during  the  life  of  the  system,  this  interpretation  must 
be  maintained  and  updated  as  changes  are  made  to  the  TCB  interface. 


test  suite.  All  TCB  functions  described  in  the  DTLS  (hoih  user  interfaces 
and  administrative  or  operator  interfaces)  must  be  tested  by  the  test  suite. 
It  is  important  for  die  test  suite  to  be  internally  coasistent;  that  is,  lor 
similar  functions  to  be  tested  in  similar  ways.  It  is  also  important  for  the 
test  suite  to  be  wcll-strcciurcd;  as  much  as  possible,  its  organization 
sliouk  follow  dial  of  die  TCB  itself,  and  test  execution  should  tic  as 
automatic  as  possible.  The  assurance  provided  by  a  test  suite  depends 
entirely  on  how  easily  one  can  determine  that  the  tests  arc  complete  and 
correct. 
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TESTING  REQUIREMENTS 

"Documentation  shall  describe  how  the  TCB  is  structured  U) 
facilitate  testing..."  IDD) 

“The  security  mechanisms  of  the  ADP  system  shali  be  tested  and 
found  to  work  as  claimed  in  the  system  documentation.”  [STj 

“Testing  shall  demonstrate  that  the  TCB  is  consistent  with  the 
descriptive  top-level  specification."  1ST] 

“The  TCB  shall  be  found  (by  ihe  NCSC  evaluation  team]  rela¬ 
tively  resistant  to  penetration."  1ST] 

Testing  is  ituended  to  show  that  the  TCB  functions  correctly,  is  described 
completely  and  correctly  by  its  DTLS,  and  is  resistant  to  attack.  Addi¬ 
tionally,  the  TCB  must  be  structured  so  that  lest  eases  can  be  constructed 
easily  and  to  allow  straightforward  arguments  for  the  completeness  of  tlic 
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THE  SECURE  DATA  NETWORK  SYSTEM: 
AN  OVERVIEW 

BY :  Gary  L.  Tatar 

Edmund  G.  Kerut 


BACKGROUND 

In  August  1986,  the  National  Security 
Agency,  the  National  Bureau  of  Standards,  the 
D  ense  Communications  Agency,  and  twelve 
c  mmunicat ions  and  computer  corporations 
initiated  a  special  project  called  the  Secure 
Data  Network  System  (SDNS) .  This  innovative 
research  program  focuses  on  designing  the 
next  generation  of  secure  computer 
communications  network  and  product 
specifications  to  be  implemented  for 
applications  with  public  and  private  data 
networks.  This  paper  will  address  the 
rationale  and  programmatic  decisions  for  the 
SDNS  project.  The  next  four  papers  cover 
details  of  the  actual  architecture,  services, 
protocols,  and  products. 

INTRODUCTION 

The  explosive  and  unprecedented  growth 
of  computer-generated  information  in  the  free 
world,  accompanied  by  rapid  advances  in 
telecommunications  and  data  processing 
technology,  has  ushered  in  the  Information 
^vge  ii,  our  society.  The  1900s  have  seen  this 
virtual  explosion  in  the  volume  of 
information  processed  through  public  and 
government  communications  and  computer 
systems.  Unfortunately,  this  growth  has  not 
been  met  with  a  commensurate  increase  in  the 
application  of  Information  Security  (INPOSEC) 
countermeasures  to  protect  data 
communications.  Tire  Soviets  and  other 
nations,  as  well  as  terrorist  and  criminal 
elements  have  the  capability  to  exploit  this 
lack  of  security  to  the  detriment  of  U.S. 
national  interests.  Exploitation  of  our 
communications  by  other  countries  may 
threaten  the  advantage  of  a  U.S.  industrial 
high  technology  base  which  has  traditionally 
given  us  the  competitive  edge  needed  to 
succeed  in  international  world  markets.  In  a 
free  society,  it  is  impossible  to  control  the 
flow  of  information  —  even  information  which 
individually  or  collectively  could  have  an 
adverse  impact  on  the  national  interest. 

There  has  been  a  long  standing  and 
effective  partnership  between  the  Government 
and  private  industry  in  meeting  the  national 
security  needs  of  the  United  States.  To 
implement  its  national  security-related 
policies,  the  Government  relies  on  industry 
for  research  and  development,  design, 
testing,  manufacturing,  installation,  and 
often  operation  or  maintenance  of 
communications  systems.  Within  the  framework 
of  the  SDNS  Program,  Government  and  industry 
are  joining  resources  and  expertise  to  make 
available  in  the  marketplace  a  large 
selection  of  INFOSEC  products  for  protecting 
both  classified  and  unclassified  information 
for  the  DoD,  civil,  and  private  sector.  The 
program  goal  is  to  make  INFOSEC,  by  virtue  o£ 
economics  and  transparency,  attractive  to  a 


large  potential  user  base.  With  the 
proliferation  of  information  security,  it 
may  be  possible  to  successfully  deprive  our 
adversaries  and  unauthorized  entities  of  our 
valuable  information  resources. 

PROGRAM  GOALS 

As  a  result,  the  basic  problem  becomes 
one  of  finding  cost-effective  approaches  to 
adding  security  to  existing  communications 
systems  and  networks.  The  major  thrust  of 
our  SDNS  strategy  is  to  assist  and  encourage 
industry  in  developing  a  wide  variety  of 
INPOSEC  products  and  systems  to  be  made 
available  in  the  marketplace  at  a  cost  and 
level  of  user  friendliness  to  equally 
encourage  widespread  use  of  these  products. 

To  implement  this  general  strategy,  we  agreed 
on  four  specific  objectives.  The  first  was 
tnat  the  companies  involved  early  in  the 
program  would  be  creating  specifications  that 
could  be  used  eventually  by  all  companies 
developing  products  in  NSA's  Commercial 
COMSEC  Endorsement  Program  (CCEP).  A  second 
decision  was  to  make  use  of  the  International 
Standard  Organization's  Open  Systems 
Interconnection  (OS1)  model  and  to 
concentrate  our  efforts  on  the  emerging  OSI 
protocols.  Since  one  of  the  objectives  of 
the  OSI  reference  model  is  to  permit  the 
interconnection  of  heterogeneous  computer 
communications  systems,  it  is  a  natural 
choice  for  our  selection  to  permit  secure 
interconnection  of  communication  systems  that 
already  have  achieved  communications 
interoperability.  The  third  goal  was  to 
develop  a  complete  security  architecture  for 
the  link,  network,  transport,  ana  application 
layers  of  tile  OSI  reference  model.  The 
fourth  goal  was  to  demonstrate  the 
feasibility  of  the  technology  and  the  cost 
effectiveness  of  the  concepts. 

SYSTEM  CAPABILITY 

SDNS  describes  the  environment  within 
which  designers  may  provide  users  with  the 
capability  of  transmitting  data  securely  over 
a  variety  of  communications  networks.  A 
user,  in  conjunction  with  a  cognizant 
security  administrator,  can  specify 
requirements  from  a  range  of  security 
services  and  levels  of  assurance.  Security 
policies  are  enforced  by  the  system 
components  and  along  with  doctrine  provide 
tlie  level  of  assurance  required  for  the 
specific  environment. 

Confidentiality  of  communications  is 
assured  by  the  use  of  government  provided, 
high-grade,  cryptographic  algorithms  for  data 
encryption  and  traffic  key  generation. 
Adherence  to  applicable  INFOSEC  doctrine, 
criteria,  guidelines,  and  good  engineering 
practices  in  the  design  and  implementation  of 
the  secure  communication  components  will 
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assure  a  successful  security  evaluation  and 
subsequent  endorsement  of  the  products. 
State-of-the-art  key  management  techniques 
will  minimize  the  burden  associated  with 
generation,  distribution,  accounting,  and 
control  of  classified  key  in  physical  form. 
Key  material  required  for  initializing  SDNS 
products  will  be  centrally  generated  and 
u  i  st r  ibuted  to  users.  Once  initialized, 
secure  communications  components  will 
independently  establish  traffic  encryption 
keys  over  the  network.  The  key  management 
components  will  also  support  electronic 
rekeying  of  the  secure  communications 
components  and  the  process  of  compromise 
reporting,  evaluation,  and  recovery. 

The  SDNS  concept  requires  inter¬ 
operability  of  secure  communications 
components  supplied  by  multiple  vendors  if 
the  same  services  are  implemented  at  the  same 
protocol  layer.  Protocol  specifications  will 
ensure  that  interoperability  of  supplied  SDNS 
services  exists. 

Each  vendor  can  provide  security 
features  beyond  the  minimum  required  set  to 
be  incorporated  in  an  SDNS  product.  Secure 
communications  components  may  exist  as  stand¬ 
alone  interface  devices  or  may  be  embedded 
into  communications  or  information  processing 
equipments  or  systems  by  vendors  based  on 
their  perception  of  user  needs.  SDNS  will 
not  preclude  the  users  selecting  various 
hosts,  communications  nett.':  .  kc,  and 
communications  services  for  securit-y 
implementation.  This  permits  a  wide  range  of 
security  products  certified  under  the 
auspices  of  SDNS,  but  otherwise  tightly 
coupled  to  and  integrated  with  a  particular 
host  architecture,  communications  network  or 
communications  service  if  they  conform  to  the 
OS1  architecture. 

Two  types  of  SDNS  equipment  will  be 
designed:  the  first  type  (Type  I)  will  be 

aimed  at  Government  classified  and  sensitive 
unclassified  national  security  information, 
and  the  second  type  (Type  IX)  will  be  used 
for  unclassified  applications  in  the 
Government  as  well  as  in  the  private  sector. 
Users  and  system  managers  will  be  able-  to 
specify  their  communications  and  security 
needs.  It  will  be  possible  for  users  to 
select  security  services  dependent  upon  the 
application,  communications  services  that  are 
needed,  and  the  degree  of  interoperabi 1 i ty 
desired.  We  expect  that  there  will  be  a 
number  of  SDNS  products  tailored  to  specific 
communications  and  security  service 
requirements.  Components  providing  a  common 
set  of  services  will  interoperate  when  SDNS 
protocols,  requirements,  and  specifications 
are  satisfied. 

There  will  also  be  an  SDNS 
infrastructure  that  contains  a  documented 
body  of  knowledge  that  will  be  needed  by  the 
people  who  desi  jn,  build,  operate,  and  use 
SDNS.  Doctrine,  procedures,  guidelines,  and 
spec i f icat ions  that  document  security 
w  magement  functions  and  activities  are 
included  in  the  infrastructure. 


PROGRAM  IMPLEMENTATION 

Since  August.  1986,  the  SDNS  Program  lias 
been  progressing  under  a  three-phase 
approach.  The  first  phase  included  the 
development  of  the  overall  concepts, 
services,  architecture,  and  key  management 
techniques.  Because  of  the  large  number  of 
Government  and  industry  participants,  several 
working  groups  were  formed  to  concentrate 
expertise  on  specific  problems.  The  Protocol 
Working  Group  focused  on  defining  the 
services  and  the  protocols.  The  Access 
Control  Working  Group  developed  a  methodology 
for  distributing  access  control  approval  at 
the  commun i ca t i on  end  points.  Using  the  DoD 
Trusted  Computer  System  Evaluation  Criteria 
known  as  the  "Orange  Book",  the  INFOSEC 
Working  Group  studied  the  SDNS  concepts  and 
protocols  to  develop  the  appropriate  criteria 
for  which  the  SDNS  devices  will  be  evaluated 
against.  The  Key  Management  Working  Group 
defined  the  requirements  for  the  public  key 
based  system  that  SDNS  will  use. 

For  this  first  phase,  in  addition  to  the 
participants  from  NBS  and  DCA,  NSA  awarded 
contracts  to  Analytics:  AT&T;  Bolt  Beranek 
and  Newman  (BBN);  Digital  Equipment 
Corporation  (DEC);  GTE;  Honeywell;  Hughes; 

IBM;  Motorola;  Unisys;  Wang;  and  Xerox.  In 
Phase  I,  the  first  task  was  the  development 
ol'  a  broad  communications  security 
architecture,  i.e.,  the  set  of  guidelines, 
constraints,  and  rules  to  implement  secure 
communications  over  public  anu  private  data 
commun i ca t ions  networks.  A  range  of  threats 
to  data  communications,  a  range  of 
environments  that  the  architecture  will  be 
applied,  and  a  general  eommuni ca t i ons 
architecture  were  all  factors  in  the 
development  of  the  security  architecture. 

The  OS I  reference  model  is  the  communications 
model  used  to  establish  a  framework  for 
coordinating  the  development  of  the  security 
architecture  services  and  related  elements, 
which  would  be  applied  appropriately  in  the 
circumstances  for  which  protection  is 
requi red . 

After  definition  of  the  architecture  and 
services,  the  Protocol  Working  Group 
emphasized  the  development  of  end-to-end 
encryption  protocols  at  layers  3  and  4  as 
well  as  electronic  mail  services  compatible 
with  X.400  at  layer  7.  Because  a  market 
exists  for  SDNS  products  at  layers  2,  3,  and 
4,  we  decided  that  a  key  management  protocol 
that  could  service  these  three  layers  was 
needed.  This  led  to  the  definition  of  a  key 
management  protocol  as  an  applications  entity' 
existing  at  layer  7  in  the  OSI  model. 

As  of  August  1987,  the  first  phase  of 
the  SDNS  prograF  has  been  completed.  The 
architecture  and  protocol  specifications  have 
been  drafted  as  have  been  the  key  management 
and  access  control  planning  documents.  The 
program  is  now  in  a  development,  testing,  and 
validation  phase  and  is  beginning  to  focus  on 
writing  the  protocols  and  developing  the 
INFOSEC  products  that  will  merge  COMPUSEC  and 
COMSEC  technology. 
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Since  the  protocol  specifications  will 
eventually  be  made  available  to  vendors 
developing  INFOSEC  products  under  USA’s  CCEP, 
this  phase  will  serve  to  test  both  the 
specifications  themselves  and  the  operational 
characteristics  of  the  security  protocols  on 
communications  networks.  The  original 
concept  of  combining  security  protocols  with 
off-the-shelf  network  and  transport  protocols 
will  be  proven.  An  added  benefit  to  be 
gained  from  this  phase  is  the  demonstration 
to  both  potential  vendors  and  users  that 
interoperability  of  multi-sourced  INFOSEC 
products  is  possible. 

During  the  communications  testing  and 
interoperability  testing  to  be  conducted  next 
year,  we  expect  to  add  substantial  detail  to 
the  protocol  and  interoperability 
specifications.  This  is  expected  to  make  it 
easier  for  companies  that  follow  to  build 
interoperable  hardware . 

CONCLUSION 

While  the  SDNS  Program  has  recently 
completed  its  first  phase,  it  is  still  a 
research  project  several  years  from  providing 
actual  hardware  capable  of  protecting  our 
nation's  data  information.  It  has,  however, 
offered  twelve  companies  an  opportunity  to 
work  together,  and  with  DCA,  NBS,  and  NS A,  to 
influence  the  next  generation  of  INFOSEC 
products.  With  the  rapid  proliferation  of 
data  communications  and  the  ease  of  access 
into  networks  that  are  growing  daily,  we  must 
preserve  our  military,  scientific,  and 
technological  edge.  We  must  take  whatever 
steps  are  necessary  --  before  a  system 
becomes  operational  —  to  provide  the  United 
States  the  means  for  ubiquitous  data  security 
that  is  so  badly  needed. 
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ABSTRACT 

The  Secure  Data  Network  System  (SDNS)  in¬ 
cludes  both  support  for  secure  communica¬ 
tions  between  users  and  a  key  management 
capability.  The  major  elements  in  the 
system  are  the  Key  Management  Center  (KMC) 
and  the  SDNS  terminals,  which  can  be  intel¬ 
ligent  terminals,  workstations  or  host  com¬ 
puters.  The  SDNS  architecture  is  consis¬ 
tent  with  the  ISO  OS I  communications 
architecture  and  protocols  as  veil  as  with 
the  DoD  protocol  suite.  As  presently  de¬ 
fined,  it  provides  security  services  at 
four  layers  of  the  OSI  architecture  —  link 
layer,  network  layer,  transport  layer,  and 
application  layer  (for  electronic  mail). 
The  SDNS  program  has  developed  standards 
for  network,  transport  and  electronic  mail 
protection;  link  layer  standards  have  been 
deferred  as  not  critical  for 
interoperability  across  the  network.  In 
addition,  protocols  have  been  defined  for 
key  management,  including  communication  of 
access  control  information  and  negotiation 
of  communications  protocol  parameters. 


The  Secure  Data  Network  System  (SDNSj  is 
intended  to  provide  secure  data  communica¬ 
tions  services  to  a  variety  of  DoD  and  com¬ 
mercial  users.  These  services  include  key 
management  and  system  management  capability 
as  well  as  the  encryption,  authentication, 
and  access  control  of  user  data.  During 
the  concept  definition  phase  personnel  from 
eleven  contractors,  NSA,  NBS,  and  other 
government  agencies  participated  in 
determining  the  security  services  to  be  of¬ 
fered,  the  system  architecture,  system  man¬ 
agement  and  access  control  requirements  and 
mechanisms,  and  the  key  management  and  se¬ 
cure  communications  protocols.  This  paper 
will  focus  on  the  protocols  and  system  ar¬ 
chitecture. 

SDNS  provides  security  compatible  with  the 
International  Standards  Organization  (ISO) 
Reference  Model  for  Open  Systems  Intercon¬ 
nection  (OSI)  .  Figure  1  shows  the  0S1 
protocol  architecture.  SDNS  terminals  and 
the  SDNS  Key  Management  System  (KMS)  com¬ 
municate  using  OSI  protocols.  Terminals 
may  be  connected  to  each  other  and  to  the 
KMS  through  local  area  networks,  public  or 
private  data  networks  or  telephone  links, 
as  shown  in  Figure  2.  The  secure  communi¬ 
cations  protocols  offer  encryption  services 
at  application,  transport,  network  or  link 
layers;  the  key  management  and  system  man¬ 
agement  protocols  utilize  the  OSI  manage  • 
ment  approach  and  are  application  layer 
protocols  between  management  application 


entities.  Figure  3  shows  the  placement  of 
the  SDNS  protocols  within  the  OSI  frame¬ 
work.  The  security  services  at  each  layer 
are  a  subset  of  the  services  described  in 
the  Security  Addendum  to  the  OSI  Reference 
Model  . 


The  OSI  Protocol  Architecture 
Figure  1 
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Placement  of  SDNS  Protocols 
Figure  3 


KEY  MANAGEMENT 


The  heart  of  SDSN  is  t.he  Firefly  keying 
system.  Each  terminal  has  a  unique  fire¬ 
fly  key  which  is  bound  together  with  a 
non-forgeable  certificate.  The  certificate 
identifies  the  terminal  and  specifies  its 
sccurity-relevent  characteristics.  Two 
5 DNS  terminals  desiring  to  communicate  ex¬ 
change  certificates  and  keying  information 
(the  Firefly  exchange)  and  make  access  con¬ 
trol  decisions  based  on  the  identifying  in¬ 
formation.  The  exchange  generates  a  traf¬ 
fic  key  which  is  unique  to  the  two 
terminals  and  which  is  new  for  that  key  ex¬ 
change.  If  communication  is  permissible, 
the  terminals  then  negotiate  the  communica¬ 
tions  parameters  for  use  of  the  traffic 
key . 

The  Firefly  keys  and  certificates  are  is¬ 
sued  by  the  Key  Management  Center,  which 
receives  key  orders  and  maintains  account¬ 
ing  information,  but  is  involved  in  neither 
the  terminal  to  terminal  communication  nor 
fo:.nation  of  traffic  keys.  Initial  deliv¬ 
ery  of  Firefly  keying  material  from  the  KMC 
is  physical  and  consists  of  either  op¬ 
erational  key  or  seed  key.  These  are 
similar  except  that  seed  key  can  only  be 
used  for  connecting  to  the  KMC  for  conver¬ 
sion  to  operational  key.  Operational  keys 
are  classified  at  the  level  of  the  traffic 
which  they  protect;  seed  keys  are  always 
unclassified.  The  KMC  also  nrovides  an 
electronic  rekey  service  for  terminal  op¬ 
erational  keys. 

Besides  the  real-time  Firefly  exchange  be¬ 
tween  the  terminals,  the  system  also  pro¬ 
vides  a  mechanism  whereby  a  terminal  can 
provide  Firefly  keying  information  ahead  of 


time  (for  example,  by  posting  its  cer¬ 
tificate  and  keying  information  on  a  bul¬ 
letin  board) .  This  can  be  used  by  a  second 
terminal  to  generate  a  traffic  key  for  se¬ 
cure  electronic  mail. 

The  protocol  working  gioup  for  SDNS  lias  de¬ 
fined  a  Key  Management  Frotocol  (KMP)  which 
is  used  for  seed  key  conversion,  electronic 
rekey,  real-time  Firclly  exchange,  and  up¬ 
date  of  terminal  traffic  keys.  This  is  an 
application-layer  protocol,  designed  to  be 
compatible  with  the  ISO  OSI  Management  Ser¬ 
vices  architecture.  The  communications  arc 
between  Key  Management  Application  Entities 
(KMAE)  in  the  terminals  and  in  the  KMC. 
Each  KMP  transaction  includes  a  Firefly  ex¬ 
change  between  the  KMAEs  to  establ  ish  a 
traffic  key  and  then  a  secure  exchange,  of 
security-services  data  using  that  traffic 
key.  The  successful  use  of  the  traffic  key 
validates  the  identities  of  the  communicat¬ 
ing  devices  and  rests  the  key.  The  ex¬ 
change  of  security  services  data  in  the 
real-time  key-exchange  transaction  is  used 
to  convey  additional  access  control -related 
information  arid  to  determine  the  parameters 
for  use  of  the  traffic  key  in  encrypting 
user  data.  The  same  KMP  exchange  is  used 
for  generating  and  validating  traffic  keys 
for  the  network  layer  and  transport  layer 
encryption  protocols  currently  defined  for 
SDNS;  it  will  also  be  used  for  link  encryp¬ 
tion  and  other  real-time  encryption  proto¬ 
cols  when  they  are  defined.  The  KMP  proto- 
<70 1  does  not  sunnnrt  secure  electronic  mail 
keys;  these  ate  generated  by  a  uiffeiont, 
non-real-time  Firefly  exchange,  described 
in  the  section  of  this  paper  on  electronic 
ma  i  1 . 

Application  layer  key  management  protocols 
allow  use  of  a  common  set  of  management 
protocols  across  all  SDNS  devices,  indepen¬ 
dent.  of  which  user  services  the  devices 
provide.  They  also  allow  the  system  to 
evolve  and  device  manufacturers  to  add  new 
user  services  without  impacting  their 
interoperability  with  the  key  management 
system . 


END-TO-END  ENCRYPTION 

In  packet  networks  and  internets,  the  term 
end-to-end  encryption  has  been  used  to  re¬ 
fer  to  an  encryption  scheme  that  encrypts 
user  data  but  provides  unencrypted  network 
headers  so  that  the  data  can  be  delivered 
through  the  packet  network.  This  type  of 
encryption  must  be  above  the  network,  proto¬ 
col  in  the  hierarchy,  since  the  network 
headers  are  not  encrypted.  In  order  to 
provide  encryption  service  in  a  uniform 
manner  to  a  variety  of  applications,  it 
should  be  as  low  as  possible  in  the  proto¬ 
col  hierarchy.  This  kind  of  argument  has 
led  to  encryption  protocols  at  the  top  of 
the  network  layer  (at  the  internet  layer 
in  the  DoD  architecture)  and  at  the  trans¬ 
port  layer  of  protocol.  There  is  not  yet 
agreement  among  network  security  experts  as 
to  which  of  these  is  the  more  appropriate 
choice.  DoD  projects  have  primarily 
focused  on  the  internet  layer;  ISO  and  com¬ 
mercial  efforts  have  been  at  the  transport 
layer.  The  Security  Addendum  t  ■■  the  OSI 
Reference  Model  allows  either  choice. 
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f, 'Jl-l.s  has  defined  network  and  transport  en¬ 
cryption  protocol;;  which  arc  consistent 
with  each  other  in  format  and  in  basic  ser¬ 
vices.  This  consistency  will  allow  SDNS 
system  developers  to  implement  one  or  both 
of  those  protocols  in  an  efficient  manner. 
It  will  promote  greater  interoperability  cl 
SDNS  systems  and  will  also  simplily  the 
task  of  security  evaluation  of  these  sys¬ 
tems.  The  SDNS  transport  protocol,  SP4,  is 
defined  as  an  addendum  to  the  ISO  Transport 
Protocol  .  The  SDNS  network  protocol,  EP3, 
is  defined  as  a  sublayer  of  the  network 
protocol  which  resides  directly  below  the 
transport  layer. 

The  SP3  and  SP4  protocols  have  been  devel¬ 
oped  as  part  of  an  ISO  protocol  suite. 
However,  the  layer  interface  between  the 
ISO  transport  protocol  TP4  ^  and 
connection] ess  network  protocol  CLNP  is 
similar  to  the  interface  between  the  DoD 
protocols  TCP  and  IP,  and  the  service 
definitions  of  CLNP  and  IP  are  almost  iden¬ 
tical.  This  leads  to  the  possibility  of 
SP3  and  ST4  implementations  which  work  with 
the  DoD  protocols.  These  implementations 
will  be  useful  in  securing  the  many  exist¬ 
ing  systems  now  using  TCP  and  IP. 


SP3  and  SP4  Services 

The  services  provided  by  ST  (a  short  term 
for  either  SP3  or  SP4 )  are  negotiated  by 
the  KMP  protocol  hefore  the  key  is  put  into 
use .  Both  services  and  foimat  are  fixed 
for  each  traffic  key,  although  SP3  and  SP4 
each  support  several  options.  The  basic 
services  provided  by  SP  are  confidentiality 
and  connectionless  integrity,  as  defined  in 
the  OS I  Security  Addendum;  cither  or  both 
services  can  be  negotiated.  In  addition, 
because  the  SDNS  key  exchange  provides 
pairwise  keys,  SP  also  provides  source  au¬ 
thentication  of  the  protected  data  units. 
SP  is  an  encapsulating  protocol;  it  oper¬ 
ates  on  a  unit  of  data,  and  either  encrypts 
it,  provides  an  integrity  check  on  it,  or 
both.  SP  allows  the  option  of  including 
additional  information  with  the  data  in  an 
SP  header,  such  as.  for  example,  security 
labels  or  network  service  access  point 
(NSAP)  addresses.  All  such  optional  infor¬ 
mation  is  bound  to  the  data  and  protected 
by  the  encryption  and/or  the  integrity 
chock.  Figure  4  shows  the  SP  header  for¬ 
mat  . 

SP  operation  is  intended  to  be  very  simple, 
so  as  to  facilitate  any  necessary  certifi¬ 
cation.  SP  operates  independently  on  each 
unit  of  data  that  is  encrypted  or  de¬ 
crypted.  It  docs  not  include  capabilities 
tor  sequencing,  acknowledging  or 
t  etransmitting  data  units,  although  ttie 
transport  protocol  associated  with  SP4  or 
above  SP3  may  have  this  capability.  EP  ro¬ 
bes  on  the  network  protocol  below  it  to 
provide  communications  service.  If  ST  op¬ 
erates  over  a  connection-oriented  network 
protocol,  it  will  provide  the  same  quality 
of  service  as  the  network  protocol,  but 
will  not  guarantee  the  sequence  integrity, 
since  it  docs  not  protect  network  layer  se¬ 
quencing  information. 
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SP  Header  Format 
Figure  4 


EP3  and  SP4  provide  the  same  basic  security 
servicer.  with  the  same  encryption 
mechanisms,  they  operate  on  the  same  user 
data,  and  they  use  the  same  format.  They 
can  interoperate  with  each  other  if  compat- 
ibleoptions  arc  chosen.  Each  protocol  has 
been  defined  to  include  a  set  of  compatible 
options,  and  each  also  includes  some  addi- 
l  iOi'ial  Capabilities  ctppx  Opi  ia  L.tx  to  the 
layer  in  which  it  operates. 


SP3  Optional  services 

In  the  OS I  architecture,  the  transport 
layer  is  the  lowest  layer  which  is  strictly 
end-to-end;  the  network  layer  can  operate 
through  relays  (packet  switches  or  gate¬ 
ways)  .  When  end-to-end  encryption  is  done 
at  the  network  layer,  as  in  SP3 ,  there  is 
an  option  of  terminating  the  encryption  at 
a  gateway,  allowing  users  oi  a  local  area 
network  to  share  the  cost  of  encryption  de¬ 
vices.  Gateway  encryption  devices  also  al¬ 
low  interoperation  through  the  gateway  of 
users  with  different  encryption  systems  if 
they  use  the  same  communications  protocols 
(see  Figure  S) . 
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In  order  to  support  gateway  encryption, 
theie  must  be  a  means  ot  routing  t  lie  en¬ 
crypted  data  through  the  lion-secure  network 
to  the  gateway  which  has  t  lie  encryption 
key,  as  well  ns  a  means  of  routing 
unencrypted  data  to  the  correct  gateway  lor 
encryption.  In  an  internetwork  with  few 
gateways,  the  routing  may  be  implicit  in 
t lie  host  address,  but  in  general,  there  can 
bo  several  gateways  into  the  same  network. 
In  addition,  since  the  key  at  a  gateway  au¬ 
thenticates  the  gateway  but  not-  each  host 
computer  on  the  network  behind  the  gateway, 
there  must  be  some  means  other  than  the 
Firefly  exchange  to  provide  source  autlien- 
t i eat  ion. 

FP3  has  the  capability',  it  this  service  in 
negotiated  by’  KMP,  of  including  source  and 
destination  address  information  in  its  pro¬ 
tected  header.  If  the  destination  host  is 
on  a  network  behind  an  SP3  gateway,  the 
unencrypted  (black)  network  header  indi¬ 
cates  the  destination  address  of  the 
decryption  gateway,  and  the  destination 
host  address  in  the  SP3  header  allows  the 
gateway  to  forward  the  data  correctly  after 
decryption.  Similarly,  the  protected  ad¬ 
dress  allows  an  encrypting  gateway  to  indi¬ 
cate  the  actual  source  of  the  data  in  the 
SP3  header  and  its  own  address  in  the  black 
network  header.  SP3  gateways  can  convert 
between  SP3  with  a  black  network  protocol 
and  a  local  protocol  without  encryption,  as 
shown  in  Figure  6. 
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SIM  js  a  part  ol  the  transport  protocol, 
TP.  because  of  this,  it  lias  access  to 
transport  protocol  information,  such  as  se¬ 
quence  numbers  and  connection  open  re¬ 
quests.  KP4  has  defined  some  optional  ser¬ 
vicer-  which  take  advantage  ol  its  position 
in  the  transport  layer.  both  HP3  and  JIM 
allow  various  keying  granularities,  includ¬ 
ing  per  pair  ol  SDNS  entities  and  per  NHA1 
pair.  SIM  also  allows  a  key  per-  transport 
connection,  which  ties  the  protocol  data 
units  to  a  specific  connection  identifier, 
when  used  with  the  TIM  protocol,  HIM  can 
provide  data  stream  integrity.  The  integ¬ 
rity  service  uses  the  transport  sequence 
numbers,  which  are  protected  by  SIM  and  an 
added  mechanism  for  gracefully  closing  the 
connection. 


ELECTRONIC  HAIL  KNCltYP'l  }  ON 

The  SDNS  protocol  for  secure  el ecr tonic 
mail  is  an.extcnoi on  of  CCl'l'T  recommenda¬ 
tion  X  .  4  00J .  This  standard  defines  the 
electronic  mail  service  provided  by  two  en¬ 
tities:  a  mail  user  agent  (HA)  and  a  mail 
transfer  agent  (MTA)  .  'lire  user  agent  acts 
on  beliall  ol  a  particular  user  and  allows 
him  or  her  to  generate  and  roeaive  mail. 
The  mail  transfer  agent  is  responsible  1  er¬ 
got  ting  the  mail  through  the  network  from 
user  agent  to  user  agent.  MTAs  can  reside 
in  the  same  computer  systems  as  pas  or  they’ 
can  reside  in  mail  relays.  Their  function 
is  analogous  to  the  post  office.  The  SUNS 
protocol  is  at  the  UA  sublayer  and  assumes 
that  MTAs  may  be  untrusted.  Mail  remains 
encrypted  from  user  agent  to  user  agent, 
through  any  relays. 

The  real-time  Firefly  exchange  is  not  used 
lor-  electronic  mail.  The  SDNS  mail  proto¬ 
col  uses  a  staged  Firefly  exchange  in  which 
a  user  who  wishes  to  receive  secure  mail 
posts  his  cert  i  f  iccate  and  some  public  key¬ 
ing  information  on  a  bulletin  board  or 
gives  it  to  a  sender  in  some  other  way. 
The  sender  uses  the  posted  in  form.it  ion 
along  witii  his  own  private  information  to 
construct  a  traffic  key,  which  is  unique  to 
the  sender-receiver  pair. 
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SP3  and  IP 


Figure  6 


If  it.  is  necessary  to  carry  more  network 
protocol  information  across  a  black  network 
lor  use  in  a  destination  red  network,  SP3 
offers  the  option  of  protecting  an  entire 
Connectionless  Network  Protocol  (CLNP) 
header.  This  option  simplifies  the  op¬ 
eration  of  the  SP3  gateways,  but  requires 
SP3  protocols  at  both  gateways  and  hosts  to 
include  the  CLNP  functionality. 


The  protocol  accomodates  multiple  address¬ 
ees  by  using  a  single  message  key  to  en¬ 
crypt  the  message  and  then  using  a  pairwise 
key  lor  each  addressee  to  encrypt  both  the 
message  key  and  an  integrity  function  of 
the  message.  The  message  header  includes 
the  sender’s  certificate.  It  also  in¬ 
cludes,  for  each  addressee,  the  public  key¬ 
ing  information  needed  to  construct  his 
pairwise  key,  and  the  encrypted  key  and  in¬ 
tegrity  cheek  word.  Privacy  of  the  message 
is  protected  because  only  the  correct  re¬ 
cipients  can  construct  the  pairwise  keys 
and  decrypt  the  message  key.  The  source  ol 
the  message  is  authenticated  by  the  binding 
between  the  sender's  certificate  and  each 
pa j  rwisc  key. 
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The  electronic  mail  protocol  includes  an 
optional  electronic,  signature.  This  will 
provide  the  additional  service  of 
non-repudiation,  as  distinct  from  source 
authentication,  allowing  the  receiver  to 
prove  the  identity  of  a  sender  to  a  third 
party . 


FUTURE  SERVICES 

The  concept  definition  phase  of  SDNS  has 
concentrated  on  defining  interoperability 
requirements  for  the  key  management  ser¬ 
vices,  for  end-to-end  encryption  and  for 
electronic  mail.  Once  the  protocols  for 
these  functions  are  implemented  and  tested, 
jt  is  likely  that  additional  functionality 
will  be  standardized  and  provided.  Link 
encryption  is  the  most  often  used  encryp¬ 
tion  method  and  can  be  included  within  SDNS 
in  a  reasonably  straightforward  manner. 
Initial  standardization  was  deferred  prima¬ 
rily  because  of  the  multiplicity  of  commu¬ 
nications  protocols  at  the  link  and 
physical  layers,  but  also  because  link  en¬ 
cryption  io  better  understood  than  either 
er.d-to-end  or  electronic  mail  encryption. 
Application  cr  presentation  layer  encryp¬ 
tion  for  real-time  data  transfer  is  another 
likely  development.  The  encapsulation 
techniques  already  designed  for  mail, 
end-to-end- encrypt  ion  and  the  KMP  service 
exchanges  can  be  a  useful  model  for  file 
encryption.  SDNS  already  allows  connection 
over  a  variety  of  public  data  networks,  lo¬ 
cal  area  networks  and  the  telephone  net¬ 
work;  this  variety  is  likely  to  inc^f:ase 
and  perhaps  to  include  ISDN.  All  of  these 
expanded  capabilities  are  consistent  with 
the  current  SDNS  architecture  and  the  lay¬ 
ered  OS I  protocol  approach. 
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INTRODUCTION 


The  Secure  Data  Network  System  (SDNS)  project  is 
developing  a  security  architecture  within  the 
Organization  of  International  Standardization's  (ISO) 
Open  Systems  Interconnection  (OSI)  computer  network 
model!)].  The  security  architecture  isdesigned  to 
provide  several  security  services  to  the  user  of  an  OSI 
network^)  The  architecture  includes  security  protocols 
between,  peer  entities  of  the  OSI  architecture  The  SDNS 
architecture  isdesigned  to  satisfy  the  security 
requirements  of  both  classified  and  unclassified 
applications.  The  cryptographic  algorithms  used  for 
data  confidentiality,  integrity  and  key  distribution  have 
been  defined  but  are  not  discussed  in  this  paper 

Thp  SDNS  project  began  during  the  summer  of  '986. 
Phase  I, completed  in  mid-1987, specified  thesecurity 
architecture  The  SDNS  architecture  concentrates  on  the 
confidentiality,  integrity,  identification  /authentication, 
and  access  control  security  services  Non  repudiation  is 
of  secondary  interest.  SDNS  provides  security  services  in 
four  of  the  seven  layers  in  the  ISO  model 

The  application  layer  (layer  7)  provides  for  application 
specific  access  to  network  services.  SDNS  examined  the 
X  400  message  handling  system  (electronic  mail)  SDNS 
serum  electronic  mail  provides  all  four  of  the  major 
security  services  and  sender  non  repudiation 

The  physical  layer  (layer  1)  provides  a  physical 
connection  for  the  transmission  of  data  by  electrically 
encoding  the  data  for  a  specific  medium  The  SDNS 
architecture  provides  for  confidentiality  at  this  layer  It 
is  the  only  layer  in  the  SDNS  architecture  which  provides 
traffic  flow  confidentiality 

1  he  network  layer  (layer  3)  provides  message  routing 
and  relaying  between  interconnected  networks  and  end 
systems  on  the  same  network  The  SDNS  architecture 
provides  all  four  of  the  major  security  services  at  this 
layer  Connectionless  confidentiality  and  integrity  are 
provided  Identification  /  authentication  and  access 
control  are  of  the  end  systems  It  is  the  only  layer  in  the 
SDNS  architecture  winch  provides  for  encipherment  at 
gateways  to  support  "red"  networks 

The  transport  layer  (layer  4)  provides  reliable, 
transparent  transfer  of  data  between  end  systems 
Again,  SDNS  provides  all  four  of  the  major  security 
services  at  tins  layer  f  his  paper  discusses  these  security 
services  and  protocol  that  implements  them  1  ho  paper 
also  outlines  the  requirements  for  key  management. 

The  Security  Protocol  at  Layer  4  (SIM)  was  developed  by 
the  SDNS  Protocol  Working  Group  SP4  provides  either 
connectionless  or  connection  oriented  confidentiality 
depending  on  the  cryptographic  key  granularity 
Likewise,  cither  connectionless  or  connection  oriented 
integrity  may  be  selected  Peer  entity  authentication 
and  access  control  are  provided  in  conjunction  with  the 
key  manager 

T he  following  objectives  were  established  m  designing 
SP4 


•  provide  secure  end-to-end  reliable  service 
independent  of  network  technology 

•  provide  confidentiality  and  integrity 
cryptographic  protection  continuously  from  one 
end  system  to  another 

•  provide  ease  of  implementation  when  red/black 
separation  is  required 

•  support  both  host  to  host  keying  and  transport 
connection  keying 

•  sup po rt  many  ciyp tog raphic  algorithms 

•  support  many  diffeient  generic  transport 
protocols 

•  minimize  changes  to  existing  transport  services 
and  protocols 

•  minimize  the  effort,  cost  and  time  required  to 
achieve  security  certification  for  classified 
applications 

•  minimize  the  bandwidth  of  covert  channels  (i  e  , 
information  paths  that  wouid  allow  unpi uit-cied 
data  to  exit  from  an  end  system) 

•  allow  implementatic  n  within  end  systems  with 
varying  levels  of  trust 

In  order  to  satisfy  the  selected  set  of  objectives,  an 
encapsulation  approach  was  taken  .  Transport 
encapsulation  security  was  coined  to  denote  that 
whatever  the  transport  entity  produced  to  send  to  a 
peer  transport  entity  was  encapsulated  in  a  security 
envelope  This  new  envelope,  called  a  Secure 
Encapsulated  Transport  Protocol  Data  Unit  ,  could  then 
be  sent  through  any  network  A  simple  format  was 
defined  and  the  required  security  transformations  were 
specified 

KEY  MANAGEMENT  SUPPORT 

The  keys  provided  by  the  key  manager  are  used  by  SP4 
to  provide  confidentiality  and  integrity  Access  control 
and  authentication  decisions  are  made  before  the  key 
identifier  is  delivered  to  SP4  SP4  enforces  these  access 
consol  decisions  by  checking  the  labels  on  individual 
protocol  data  units  (PDU) 

Key  Generation 

SP4  was  designed  to  be  independent  of  encryption 
algorithm  and  method  of  key  distribution  Either 
symmetric  or  asymmetric  algorithms  can  be  used 

SDNS  uses  SP4  with  a  symmetric  key  algorithm  SP4 
depends  on  the  key  manager  to  establish  and  update 
traffic  keys  Tfie  SDNS  key  manager  uses  public  key 
cryptography  to  generate  these  traffic  keys 


Key  Granularity 

One  of  three  key  granularities  is  selected  when  the  key  is 
established. 

•  Key  per  end  system  NSAP  pair.  One  key  protects 
ali  transport  connections  established  between  a 
pan  of  transport  entities  in  two  end  systems. 

•  Key  per  end  system  NSAP  pair  and  security  label 
As  above  with  the  addition  that  the  protection 
extends  to  a  single  security  level  or  range. 

•  Key  per  transport  connection  One  key  will  be 
used  to  protect  each  transport  connection 
independently  from  all  others  T ransport 
connections  are  assumed  to  be  single-level. 
Transport  connection  keying  is  required  for 
connection  oriented  integrity. 

A  SP4  transport  entity  may  simultaneously  support  any 
or  all  of  these  key  granularities.  Security  options  are 
associated  with  each  key  identifier,  this  technique 
permits  traffic  to  be  protected  to  varying  levels. 

Security  Option  Association 

When  one  of  the  transport  entity  pair  keying 
alternatives  is  selected,  the  following  attributes  may  be 
associated  a  key  identifier. 

•  Encryption  algorithm 

•  Confidentiality  (encrypt  or  not) 

•  Message  Authentication  Code  (MAC)  iengih 
(including  none) 

o  Security  label  in  each  protocol  data  unit  (or  not) 

•  Set  or  range  of  security  levels  which  may  be 
transmitted  under  the  key 

If  transport  connection  keying  is  selected,  the  following 
attributes  may  be  associated  with  a  key  identifier 

•  Encryption  algorithm 

•  Confidentiality  (encrypt  or  not) 


•  Message  Authentication  Code  (MAC)  length 
(including  none) 

®  Security  label  in  each  protocol  data  unit  (or  not) 

•  Connection  truncation  protection  (or  not) 

PROTOCOL  AND  DATA  FORMAT 

SP4  povides  many  security  services.  This  section  further 
defines  these  services  and  discusses  how  each  is 
provided  SP4  relies  on  the  key  manager  and  generic 
transport  services,  the  dependencies  will  be  highlighted. 

Protocol  Data  Unit  Format 

Figure  1  illustrates  the  format  of  the  protocol  data  unit 
(PDU)  used  in  SP4.  The  SE  PDU  is  formed  by  computing 
the  message  authentication  code  (MAC)lfi  and  then 
performing  encryption. 

Four  heading  fields  are  transmitted  in  the  dear  The 
first  field  is  the  Length  Indicator  (LI);  it  simply  points  to 
the  beginning  of  the  encrypted  in  formation  Second  is 
the  type  field,  SP4  PDUs  always  have  SE  for  their  type. 
Next  is  the  key  Identifier  (KE  V  ID).  The  key  identifier 
names  the  key,  including  a  name  permits  different 
connections  to  be  cryptographically  separated  on  the 
network.  Finally,  the  Initial  Vector  (sometimes  called 
the  Ml)  appears  The  recipient  uses  the  Initial  Vector  to 
initialize  the  decryptor,  this  value  permits  the  PDUs  to 
be  decrypted  even  if  they  arrive  out  of  order 

The  encrypted  header  also  contains  four  f deeds  The 
Security  label.  Final  Sequence  Numbers  (FSN),  and  Pad 
are  optional;  only  those  which  are  needed  are  included 
The  i  i  points  to  the  beginning  of  the  user  o'did  The 
security  label  indicates  the  sensitivity  of  the  data 
contained  in  the  PDU.  1  he  FSN  eves  the  final  transport 
sequence  number  sent  and  the  final  transport  sequence 
number  received  The  FSN  is  included  in  the  closing 
PDUs  of  the  transport  connection.  Pad  >s  used  when  the 
encryption  algorithm  requires  the  PDU  to  be  a  specific 
length. 

Confidentiality 

Confidentiality  isthe  protection  of  information  from 
disclosure  to  unauthorized  individuals,  entities,  or 
processes  Connectionless  confidentiality  is  the 
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Figure  1  SE  PDU  Format 


protection  of  a  individual  PDUs.  Connection-oriented 
confidentiality  is  the  protection  of  all  PDUs  in  a 
transport  connection. 

SP4  supplies  connection-oriented  confidentiality  when 
transport  connection  keying  is  used  Otherwise, 
connectionless  confidentiality  is  provided. 

Connectionless  Integrity 

Data  integrity  is  the  protection  of  data  from  alteration 
or  destruction  Connectionless  integrity  provides 
protection  against  the  modification  of  a  individual 
PDUs. 

SP4  provides  connectionless  integrity  by  appending  a 
MAC  to  the  PDU.  The  MAC  algorithm  uses  the  same  key 
as  the  encryptor  /  decryptor,  so  an  additional  KEY-ID 
field  is  not  required  to  support  the  MAC.  The  MAC  is 
computed  on  the  entire  PDU,  including  the  plaintext 
header.  The  MAC  is  computed  before  en<  ryption  and 
checked  following  decryption 

Connection-oriented  Integrity 

Connection-oriented  integrity  includes  protection 
against  modification,  deletion,  insertion,  replay  (of 
single  PDUs  and  entire  connections)  and  reflection. 

Protection  against  modification  is  is  provided  as  in 
connectionless  integrity,  the  MAC  provides  this 
protection 

Protection  against  insertion  is  provided  by  the  MAC  and 
the  sequence  numbers  of  the  generic  transport  layer. 
These  sequence  numbers  are  part  of  the  encapsulated 
"user  data". 

Piotection  against  deletion  is  provided  by  the  same  two 
facilities  (MAC  and  transport  layer  sequence  numbers) 
plus  the  final  sequence  numbers  fields  on  the  closing 
PDUs  The  MAC  and  transport  layer  sequence  numbers 
are  sufficient  to  detect  PDU  deletions  in  the  middle  of 
connections.  The  ISO  OSI  Transport  Protocol  (TP)[4.S|  ,s 
vulnerable  to  deletion  of  the  end  of  a  connection  SP4 
includes  the  final  sequence  number  received  and  sent  on 


the  closing  PDUs  to  detect  this  truncation.  Truncation  is 
not  prevented;  it  is  detected. 

Protection  against  PDU  replay  is  obtained  if  the 
sequence  numbers  do  not  wrap  around  under  the 
connection  key  SP4  must  obtain  a  new  key  from  the  key 
manager  shouls  the  sequence  number  space  be 
exhauseted. 

SP4  must  ensure  that  each  transport  connection  is 
separately  keyed.  The  key  manager  is  responsible  for 
performing  a  liveness  check  as  part  of  key 
establishemnt.  At  connection  release,  SP4  must  also 
notify  the  key  manager  to  destroy  the  key. 

Protection  against  reflection  is  provided  if  the  KEY-ID 
for  transmit  and  receipt  are  different  This  is 
accomplished  either  by  the  use  of  different  keys  for  the 
sender  and  the  recipient  or  by  different  names  for  the 
same  key. 

Table  1  summarizes  the  division  of  responsibilities 
between  generic  transport,  SP4  and  the  key  manager  to 
achieve  connection  oriented  integrity. 

Access  Control 

Access  control  provides  protection  agamst  unauthorized 
use  of  the  resources  accessible  via  OSI  Access  control  is 
provided  by  the  key  manager  In  addition,  5P4  provides 
support  for  access  control  via  security  label  checking 
SP4  discards  any  PDUs  that  arrive  and  decrypt  but 
contain,  labels  outside  the  range  specified  for  use  with 
the  key  identifier. 

Peei  Entity  Authentication 

Peer  entity  authentication  is  the  verification  that  a  peer 
entity  in  an  association  i..  the  one  claimed  This  service 
can  be  provided  both  during  the  establishment  of  a 
connection  and  during  the  data  transfer  phase  of  a 
connection  SP4  does  not  provid  peer  entity 
authentication  at  connection  establishment  This  service 
is  provided  by  the  key  manager. 
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SP4  conforms  to  the  OSI  philosophy  of  putting  desirable 
services  in  the  lowest  layer  possible  that  can  achieve  the 
goals.  The  host-to  host  nature  of  the  transport  layer, 
the  encapsulation  strategy,  and  the  separation  of  the 
key  management  give  SP4  security  and  flexibility.  SP4 
meets  all  of  it's  design  objectives. 

Since  the  transport  layer  is  above  the  network  layer,  SP4 
passes  through  routers  and  relays  untouched  This  host- 
to-host  quality,  along  with  encryption,  fulfills  the 
following  design  objectives: 

•  provide  secure  end-to-end  reliable  service 
independent  of  network  technology 

•  provide  confidentiality  and  integrity 
cryptographic  protection  continuously  from  one 
end  system  to  another 

The  encapsulation  strategy  used  in  SP4  permits  it  to  use 
any  generic  ransport.  protocol  including  DOD's  TCP  and 
ISO  s  TP  Since  the  encapsulation  is  done  as  the  last  step 
in  the  transport  layer,  SP4  can  be  implemented  within 
the  host  or  within  the  network  front  end  processor 
When  5P4  is  impiemeiiied  in  a  iruni  end  piOCOSSOr,  the 
security  boundary  becomes  obvious  The  encapsulation 
technique  reduces  the  covert  channel  bandwidth  by 
filling  all  of  the  plaintext  SP4  heading  fields  without 
influence  from  the  user  Encapsulation  fulfills  the 
following  design  objectives. 

<t  provide  ease  of  implementation  when  red/black 
separation  is  required 

•  support  many  different  genei  ic  transport 
protocols 

•  minimize  changes  to  existing  transport  services 
and  protocols 

•  minimize  the  effort,  cost  and  time  required  to 
achieve  security  certification  for  classified 
applications 

•  minimize  the  bandwidth  of  covert  channels  (i.e  , 
information  paths  that  would  allow  unprotected 
data  to  exit  from  an  end  system) 

•  allow  implementation  within  end  systems  with 
varying  levels  of  trust 

Separating  the  key  management  from  the  SP4  protocol 
fulfills  the  remaining  two  objectives: 

•  support  both  host  to  host  keying  and  transport 
connection  keying 
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•  support  many  cryptographic  algorithms 
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ABSTRACT 

This  paper  explores  issues  which  arise  in 
applying  SDNS  security  technology  to  answer  the 
Type  II  market's  need  to  secure  commercial  and 
Government  unclassified  sensitive  information 
transmitted  across  data  networks.  The  Type  II 
environment  has  a  number  of  fundamental 
characteristics  and  requirements  which 

differentiate  it  from  the  Type  I  (Government 
classified)  environment.  Some  of  these 

characteristics  simplify  issues  which  arise  in  the 
Type  I  environment/  or  aliov»  enhanced 
functionality  to  be  offered#  but  others  introduce 
new  and  difficult  challenges  which  must  be 

addressed.  This  paper  examines  the  ramifications 
of  communications  security  for  the  Type  Ii 

environment  and  considers  the  role  that  SDNS  can 
play  in  satisfying  that  environment's  needs. 

CHARACTERIZING  THE  ENVIRONMENT 

The  potential  market  for  Type  II  SDNS 

components  can  be  divided  into  several  categories. 
DoD  unclassified  users,  civilian  Government 
agencies  and  departments.  Government  contractors, 
and  the  broader  private  sector.  In  general,  the 
non-DoD  community  is  in  a  learning  phase, 
determining  needs  for  information  security, 

XnKirmJ  n  i  r  "wmi  ini  r-  £  j  -.j ■*.  SwCUr’it,,'S  tOle  Ip.  the 

overall  information  security  picture,  and 

identifying  appropriate  mechanisms  to  answer  those 
needs.  The  requirements  of  this  emerging 
marketplace  are  still  evolving. 

Organizational  characteristics  of  the  Type  II 
environment  introduce  new  challenges  for  component 
producers.  The  Type  II  user  community, 
particularly  in  the  commercial  sector,  is  not 
oriented  to  accepting  security  practices  which 
interfere  with  operational  flexibility.  This 
places  a  premium  or.  user-friendly  key  management  . 
Potential  customers  tor  Type  II  SDNS  technology 
use  computers  with  a  broad  range  of  vendoi- 
specific  communicat ions  protocols.  These 

protocols  are  not  easily  modified  to  satisfy  a 
security  system's  needs.  This  suggests  that 
security  technology  needs  to  be  transparent  to 
vendor  protocol  characteristics.  Customers 
evaluate  security  requirement:*  against  stringent 
cost /benefit  tradeoffs,  and  adoption  of  security 
mechanisms  must  be  justified  financially  based  on 
risK  assessment  -  The  use  of  embedded 

communicat i ons  security  (COMSEC)  technology  oft "is 
a  significant  potential  to  provide  the  cost- 
effective  security  solutions  which  this 
marketplace  requires. 

ISSUES  AN!)  CUSTOMER  CONCERNS 

Many  of  the  basic  tenets  of  conunun  i  cat  i ons 
security,  its  goals,  and  the  context  in  which  it 
operates,  differ  between  the  classified  and 
unclassified  environments.  To  cite  a  tew 
examples : 

1.  Relative  to  the  Tyj  -»  I  envi  i-.-nn:1  n*  ,  Typ**  11 
environment  definitions  tor  clearances, 
sensitivity  lev*.' Is,  sensitivity  categories, 
and  data  labeling  air?  less  formal  ized  and  o 


fragmented  among  larger  numbers  of 
administrations.  Clearances  assigned  by  one 
organization  ate  not  generally  transferable 
to,  or  interchangeable  with,  those  of  other 
organizations.  Similarly,  sensitivity  levels 
and  category  definitions  arc  not  generally 
interchangeable  across  organizational 

boundaries . 

<  .  The  rule-based,  administratively-directed 
access  control  policy  associated  with  the  DoD 
clearance  lattice  and  enforced  by  Orange  Book 
A  and  B  level  hosts  (mandatory  access  control, 
in  TCSEC  parlance)  is  alien  to  the  present 
Type  II  marketplace.  In  particular,  the 
commercial  market's  security  policy  needs 
differ  significantly  from  classified  military 
needs,  as  (Clark]  has  noted.  No  analog  to  the 
TCSEC  hierarchic  security  levels  exists  across 
the  Type  II  environment.  In  principle,  the 
TCSEC  non-hierarchic  access  category  concept 
could  be  applied  to  Type  II  needs  to  segregate 
tr3de  secret  information,  proprietary 
information,  and  the  like,  but  even  this 
application  is  complicated  by  the  issues  noted 
in  1.  above.  Therefore,  it  appears  that  most 
Typo  II  access  control  will  be  identity-based, 
that  is,  making  decisions  a  function  of  the 
authenticated  identities  of  would-be 

accesso/s,  rat  .nor  than  being  based  on  ruies 
granting  access  as  a  function  of  attributes 
(e.g.,  label s>  of  data. 

3.  Data  integrity  is  emphasized  in  the  Typo  II 
environment ,  even  in  those  contexts  (such  as 
portions  of  t.he  financial  community)  which  do 
not  impose  data  confidentiality  requirements. 
In  those  Type  II  contexts  wh»'te  data 
confidentiality  is  required,  traffic  flow 
confidentiality  is  not  generally  a  concern . 

4.  In  the  Type  II  arena,  admin i st r at  or s  are  not 
commonly  concerned  with  the  prospect  that 
Trojan  horses  might  leak  data  out  of  theit 
systems  into  less  secure  environments.  The 
absence  of  this  concern  facilitates 
integration  ol  SDNS  functions  within  host 
computers . 

Other  issues  are  common  between  the  Type  I 
and  Type  II  environments,  for  example,  the 
recognized  need  for  authentication,  data 
integrity,  and  identity-based  access  contLol 
services.  Authentication  is  important  not  only 
a  prerequisite  to  access  control,  but  also  as  a 
service  in  its  own  right,  providing  trustworthy 
identification  data  for  use  by  host  computers  and 
users.  In  the  financial  community,  in  particular, 
there  is  precedent  for  an  authentication  service 
requirement  even  in  ch-  absence  of  a 

confidentiality  requirement;  authentication  and 
data  integrity  services  in  this  community  have 
traditionally  been  provided  a*  the  application 
lav**  r,  independent  of  any  con  f  ict^nt  i  a  1  1 1  y  services 
which  may  be  provided  at  1  protocol  lnyers. 

In  the  SDNS  architecture,  peer  component 
authentication  depends  on  attributes  bound  into 
th-'  cryptographic  keying  material  which  is 
rt i a*  i  i but  *-d  to  a  compunen*  in  no*1!  to  mike  it 
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operational.  The  decentralized  nature  of 
authority  in  the  Type  II  environment  strongly 
suggests  that  the  generation  and  dissemi nat ion  of 
keying  material  be  decentralized,  so  that  users' 
changing  attributes  can  be  reflected  in  a  timely 
fashion.  It  is  also  critical  that  keyrng  material 
be  available  to  Type  II  customers  in  a  cost- 
effective  manner.  These  issues  suggest  important 
technologies  1  and  policy  tradeoffs  with  regard  to 
key  management  services  for  Type  II  customers. 
Acceptance  of  SDNS  security  in  this  marketplace  is 
likely  to  depend  on  the  successful  resolution  of 
these  tradeoffs. 

Two  Type  II  environment  attributes  appear 
contradictory  and  this  apparent  cent radiction 
deserves  examinat  Lon.  On  one  hand,  some  Type  II 
customers  identify  internal  threats  to  their 
computing  installations  (e.g.,  authorized  users 
exceeding  their  authorization  and  performing 
inappropriate  actions  within  a  system)  as  a  major 
security  concern.  Despite  this  fact,  trusted 
computer  system  technology  has  not  received  major 
emphasis  in  the  Type  II  environment.  There  are 
several  possible  explanations  for  this  apparent 
dichotomy.  In  general,  the  internal  trust  level 
of  current  commercial  products  is  limited  and  lias 
not  been  a  selection  criterion  driving  users  to 
choose  one  product  instead  of  another .  When 
security  features  are  considered,  it  is  often  on 
the  simple  basis  of  their  presence  or  absence, 
rather  than  on  their  evaluated  quality.  If  a 
facility  is  incorporated  into  a  component,  it  is 
expected  to  operate  correctly  and  perform  its 
designed  functions.  For  example,  the  simple 
presence  of  an  access  control  mechanism  might 
suffice  to  satisfy  procurement  goals,  even  if  the 
mechanism's  design  or  implementation  were 
susceptible  to  malicious  subversion.  The  TCSF.i; 
emphasizes  DoD  mandatory  control?  which  lack  clear 
applicability  in  the  unclassified  environment. 
This  may  contribute  to  user  perceptions  that 
internal  computer  system  trustworthiness  is  an 
issue  primarily  relevant  to  the  classified  arena. 
Further,  the  TCSEC  emphasizes  disclosure  concerns 
over  data  integrity  concerns,  and  the  latter  are 
of  primary  importance  to  many  Type  II  customers. 

Mechanisms  to  protect  host  computers  and 
their  sensitive  data  from  unauthorized  access  via 
network  communications  channels  are  rapidly 
becoming  important  to  Type  11  customers, 
independent  of  the  internal  secuiity  level  of  the 
h  st s  being  protected.  This  is  especially  true 
when  eas i 1 y-accessed  public  or  shared  networks  are 
used,  but  the  same  mechanisms  are  often  needed  for 
private  networks  which  carry  sensitive  dr1 a,  SDNS 
COMSF.C  components  can  add  security  value  to  public 
or  private  networks,  offering  protection  against 
active  wiretapping  (ensuring  in*-»grity  or 
sensitive  data)  and  passive  wrretappina  (ensuring 
confidentiality  where  required)  .  Moreover,  51  NS 
components  can  satisfy  network-oriented  access 
control  concerns  in  a  very  strong  tabic:..  This 
en  f  n  cement  vehicle  to:  a  local  administration's 
policies  is  particularly  useful  in  establishing 
protective  boundaries  around  hosts  with  limited 
internal  COMTUSEC  assurance. 

Covert  channel  bundwi  it h  restriction  is  not 
an  important  responsibility  tor  Tyj  e  11  SIN 
components.  Attempts  by  authorized  host  users  t  ■- 
leak  information  into  unsecured  corrjr  un  i  -  at  ions 
ticili*  it'::  do  not  appert  to  1'"  a  mi-  r  c.  n-f-in. 


Provision  of  secui  rt.y  services  on  behalf  of  hosts, 
rather  than  enforcement  of  isolation  between  hosts 
and  networks,  is  the  principal  emphasis.  As  a 
specific  example,  it  will  be  common  for  SDNS- 
secured  Type  II  hosts  to  communicate  not  only  with 
other  SDNS-secuted  hosts,  but  also  with  unsecured 
hosts.  This  implies  that  Type  II  SDNS  components 
must  accommodate  selective  application  of 
encryption,  either  on  an  address-driven  basis  or 
on  request  from  an  associated  host. 

DESIGN  APPROACHES 

Potential  customers  for  Type  II  SDNS 
technology  use  a  broad  range  of  host  computers, 
which  are  supplied  by  a  large  number  of  vendors. 
In  many  cases  these  computers  communicate  using 
vendor-specific  protocols  at  upper  protocol 
.layers,  rather  than  ISO  or  DoD  standards.  It  does 
not  appear  feasible  tc  standardize  means  for 
integrating  SDNS  security  measures  within  large 
numbers  of  upper-layer  protocols  specific  to 
individual  vendors.  Fortunately,  many  of  these 
protocols  share  a  common  denominator:  they  operate 
atop  one  of  two  standard  protocols,  X.2S  (for  long 
haul  networks)  and  IEEF.-802  (for  local  area 
netwotks).  Transparent  security  mechanisms 

designed  for  use  with  these  standard  protocols  can 
provide  security  services  for  a  wide  range  of 
hosts,  independent  of  the  protocols  employed  above 
the  layer  where  protection  is  provided. 
Transparency  issues  include  performance  and 
operational  support  as  well  as  protocol 
compatibility.  For  minimal  performance  impact, 
flow  control  information  must  be  reflected  across 
SDNS  components.  For  minimal  operational  impact, 
ctatus  information  must,  also  be  reflected  across 
SDNS  components.  Since  covert  channel  bandwidth 
restriction  is  not  an  important  concern  for  Type 
II  SDNS  components,  it  is  relatively 
St  might  forward  for  Type  .'I  components  to  reflect 
such  information  and  provide  highly  transparent 
service. 

Secuiity  functions  can  be  offered  in  the  near 
term,  using  transparent  security  mechanisms 
implemented  in  standalone  SDNS  components  foi 
connection  between  a  hoot  computer  and  its  network 
interface.  An  add-on  SDNS  end-to-end  security 
"overlay"  for  a  network  car.  be  oflered  in  a  non- 
invasive  fashion,  imp>osing  minimal  disruption  on 
existing  hosts'  operations,  as  Figure  1 
illustrates.  Figure  1(a)  shows  a  group  or  hosts, 
attached  to  a  pair  of  packet  netwotks  which  arc- 
linked  by  a  gateway.  In  Figure  1(b),  SDNS 
components  are  added  to  secure  traffic  among  hosts 
A,  B,  and  C;  each  of  these  hosts  can  continue 
unsecured  comnuin  icat  ions  wit  I:  host  D. 

As  tin-  Type  11  mar  ketpiaeo' s  security 
requirement  s  mature,  it  will  become  more  likely 
lor  compute:  system  and  ii-tw-ik  component  vend.rs 
to  offer  SPNS-based  secuiity  provision  ,  either  ao 
optional  features  or  standard  facilities  within 
commercially  marketed  systems.  Tin-  use  of 

embed.!"  J  COMSF.C  component  a  and  module.-,  can  i  educe 
tire  incr  eiuen:  a  1  Cost  of  procuring  security 
featured  within  a  compu*  ei  system,  assuming  t.ha: 
cost  -e  1  f  "rt  iv>;  Tyj  e  II  CCEI*  component  s  become 
available.  The  Tyre  II  env  i  r  unm-T.t  '  a  limit-’d 
'..nce-in  about  Trojan  bosses  facilitates 

integration  of  embedded  COM  F.~,  and  also 
la -i  1  it  at  os  th"  ure  of  bl.'tlb  f  a: :  I  i  t  i  -s  pi  Cert 
Ccmmun  i'-al  iet.s  servi-es  a'  upp--:  j  t  cool  ;ay"ra. 
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(a)  Before  SDNS  Security  Overlay 


(b)  After  SDNS  Security  Overlay 


Figure  1 

SDNS  SECURITY  OVERLAY  FOR  NETWORKS 


Upper-layer  services  are  difficult  or  impossible 
to  protect  With  outboard  COMSEC  components 
interposed  on  interfaces  between  host  computers 
and  their  network  ports,  as  illustrated  in  Figure 
2(a).  Instead,  it  is  generally  necessary  to 
integrate  the  COMSEC  functions  used  to  protect 
upper-layer  traffic  within  a  peripheral  operating 
under  host  software  control,  as  illustrated  in 
Figure  2 (b) . 


(a)  COMSEC  interposed  on  Communication  Interface 


(b)  COMSEC  Integrated  as  Peripheral 


Figure  2 

COMSEC  INTEGRATION  APPROACHES 


Electronic  mail  is  an  example  of  an  upper- 
layer  communications  service  of  major  interest  to 
both.  Type  I  and  Type  II  customers.  SDNS 
protection  for  electronic  mail  is  implemented 
within  an  application  layer  use;  agent  (UA) 
process,  which  corresponds  to  an  individual  human 
user  wishing  to  send  or  receive  secure  mail. 
Electronic  mail  is  transferred  on  a  store-and- 
forward  basis  in  which  the  originator's  and 
recipient's  computers  need  not  communicate 
directly  in  real  time.  As  a  result,  true  end-to- 
end  protection  for  this  traffic  cannot  be  achieved 
below  the  application  layer.  Application  layer 
encryption  implies  that  a  large  amount  of  control 
information,  which  is  present  in  the  headers  of 
all  seven  OSI  protocol  layers,  must  be  transmitted 
as  plaintext.  Type  I  environment  concerns  may 
dictate  that  measures  be  taken  to  reduce  this 
channel's  bandwidth  (perhaps  through  use  of  lower 
layer  SDNS  mechanisms,  in  addition  to  application 
layer  mechanisms) .  As  hosts  with  enhanced  trust 
levels  become  available,  the  need  for  such 
measures  may  diminish.  In  the  Type  II 
environment,  however,  it  is  reason tble  to  offer 
SDNS  electronic  mail  security  in  the  near  term, 
without  need  for  bandwidth  restriction  measures. 


THE  PATH  AHEAD 


SDNS  technology  has  significant  potential  tc 
provide  high  quality,  cost-effective  security  for 
the  Type  II  environment.  To  realize  this 
potential,  several  important  prerequisites  must  be 
satisfied,  complementing  the  standardization 
activities  carried  out  in  SDNS  Phase  1.  Vendors 
and  evaluators  alike  must  focus  or  Type  II 


which  differ  significantly  from  those  seen  in  the 
classified  arena.  Inexpensive  Type  II  CCF.P 
modules  and  components,  the  essential  building 
Mocks  for  cost-effective  Type  II  SDNS  equipment, 
mast  become  available.  Keying  material  must  be 
available  to  users  in  a  cost-effective  fashion. 
Its  procedural  aspects  must  r.ot  impose 
unacceptable  burdens  on  network  operations  or 
administrative  structures.  If  these  conditions 
are  satisfied,  SDNS  Type  II  products  can  offer 
valuable  protection  foi  unclassified  sensitive  and 
commercial  data  network  traffic  at  a  wide  range  of 
pio.ocol  layers.  The  market  appears  poised  to 
grow  rapidly  i f  the  right  products  become 
available.  If  the  conditions  are  not  satisfied, 
it  is  less  likely  that  Type  II  SDNS  products  can 
be  produced  and  marketed  effectively,  and  hence 
less  likely  that  a  qualitative  improvement  in  the 
security  of  a  broad  range  of  data  network  trallic 
wi  ll  t  ike  place . 
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ABSTRACT 

This  paper  addresses  the  subject  of  Access 
Control  within  the  Secure  Data  Network  System  (SDNS). 
The  fundamental  elements  of  the  Secure  Data 
Network  System  are  nonforgeable  authentication 
information  and  unique  pairwise  key.  Using  these 
elements,  the  system  provides  five  security 
services;  confidentiality,  data  integrity,  non- 
repudiation,  authentication  and  access  control. 

It  is  the  prerogative  of  those  who  establish  and 
implement  a  system's  security  policy  to  choose 
the  granularity  of  access  control  they  wish  to 
enforce.  The  enforcement  should  be  consistent 
with  both  the  national  and  local  policies  governing 
a  particular  environment. 

In  this  paper  we  discuss  access  control  in  the 
framework  of  the  International  Standards  Organiza¬ 
tion's  (ISO's)  seven  layer  protocol  model.  Access 
control  can  occur  only  between  corresponding  peers 
at  different  endpoints.  An  access  control  model  and 
its  set  of  corresponding  rules  are  discussed  in  the 
contexts  of  initial  access  authorization  and  con¬ 
tinuous  enforcement.  Initial  access  authorization 
is  accomplished  through  the  process  of  Petr  Access 
Authorization  while  continuous  enforcement  takes  place 
by  means  of  t.he  Peer  Access  Enforcement  process. 

Both  of  these  processes  are  discussed  in  detail. 

Security  services  may  be  provided  in  Layers  2, 

3,  4  and  7  of  the  ISO  protocol  model.  In  separate 
sections  we  discuss  the  access  control  concerns  at 
each  of  these  layers.  These  discussions  include  the 
definition  of  requisite  E I  REFLY  certificate  and 
Protocol  Data  Unit  information  for  access  control. 

1.  INTRODUCTION:  SDNS  AUTHENTICATION  AND  ACCESS 
CONTROL 

1.1  OVERVIEW 

This  paper,  along  with  others  published  here,  is 
based  upon  the  developmental  work  accomplished  within 
the  Secure  Data  Network  System  (SDNS)  program  under 
the  auspicies  of  the  065  Special  Projects  Office. 

This  paper  addresses  access  control  within  SDNS 
and,  as  such,  represents  a  consensus  arrived  at 
within  the  Access  Control  Working  Group  (ACWG). 

Other  SDNS  working  groups,  such  as  Key  Management, 
Protocol  and  Systems  Management  address  other  major 
components  of  SDNS.  These  all  have  had  a  direct 
influence  on  the  design  features  of  the  preliminary 
SDNS  access  <  ont.rol  concepts  that  are  presented  here. 

A  variety  of  security  services  will  be  available 
tnrough  SDNS  components,  which  will  allow  eud-users 
to  specify  the  "amount"  of  protection  required 
fur  their  sensitive  classified  or  unclassified  data. 
The  SDNS  will  include  mechanisms  to  support  security 
policies  which  require  a  high  level  of  assurance  for 
mandatory  and  discretionary  access  control.  Authen¬ 
tication  and  access  control  decisions  will  differ 
from  domain  to  domain,  based  upon  the  security 
policy  fer  a  particular  domain.  SDNS  allows  for  and 
supports  this  requirement.  The  system  will  be  as 
transparent,  as  possible,  and  have  minimum  impact  on 
the  reliability  of  the  network. 


Access  Control  decisions  in  SDNS  are  made  by 
the  end-users  attempting  to  communicate.  These 
decisions  are  made  in  the  context  of  each  end-user's 
own  security  policy.  The  FIREFLY  mechanism  is  an 
intrinsic  part  of  key  management  and  distribution 
in  SDNS  and  is  the  means  by  which  an  end-user 
receives  information  to  make  access  control  decisions. 
riREFLY  provides  the  fundamental  elements  of  non - 
forgeable  authentication  information  and  pairwise 
unique  key  generation  for  SDNS.  The  SDNS  key  Manage¬ 
ment  System  will  accommodate  provision  for  a 
combination  of  centralized  and  decentralized 
functions  to  provide  the  best  security  with 
minimum  impact  on  user  flexibility.  Once  initialized, 
the  secure  components  autonomously  can  est.abl  ish 
traffic  encryption  keys  without  further  intervention. 
FIREFLY  certificates  are  mutually  exchanged  by 
peer  entities.  Access  control  is  enforced  using 
the  information  contained  in  the  FIREFLY  certificate. 

The  ACWG  has  developed  an  Access  Control  model 
to  provide  a  framework  for  the  coordination  of  a 
standard  set  of  authentication  data  and  access 
control  checks  which  will  allow  for  the  inter¬ 
communication  between  different  SDNS  users/systems 
when  their  national  and  local  policies  allow  it. 

The  model,  described  in  subsequent  sections  of  this 
paper,  includes  a  mechanism  for  continuous  access 
control  enforcement  and  a  four  tiered  mechanism  for 
determining  initial  access  author’ zation. 

2.  THE  MODEL,  PAA/PAE  AND  HOW  IT  ALL  WORKS 
2.1  INTRODUCTION 

"In  'this  section  we  describe  a  four  tiered  model 
developed  by  the  SDNS  Access  Control  Working  Group 
and  the  processes  of  Peer  Access  Approval  (PAA) 
and  Peer  Access  Enforcement  (PAL).  This  descriptive 
model  and  its  set  of  supporting  PAA/PAE  rules 
provide  a  decision  process  for  determining  access  to 
information.  The  FIRKEI.Y  certificate  defines  inputs 
to  the  decision  process.  Other  inuuts  to  the 
decision  process  (e.g.,  tables  specifying  identity 
lists  to  support  I BAC )  are  not  contained  in  the 
TIREFLY  certificate.  The  construction  of  the 
model  in  no  way  implies  that,  all  instantiations  of 
SDNS  should  support  it  in  its  entirety. 

The  SDNS  provides  two  processes  for  determining 
first  time  or  continued  access  control.  Tigure  1 
is  a  top  level  diagram  of  these  two  processes. 

The  first  provides  access  control  during  the 
opening  of  a  cryptoyrapnic  association  between 
two  peers,  called  Peer  Access  Approval  (PAA).  The 
second  procedure  provides  for  the  enforcement,  of  the 
cryptographic  association  wnile  it  is  active.  This 
process  is  called  Peer  Access  Enforcement  (PAE). 
Results  obtained  from  the  PAA  process  are  passed  to 
the  PAE  process  through  the  Enforcement  Vector  (LV). 
The  PAA  and  PAE  processes  are  performed  at  each  end 
of  the  association  with  each  peer  enforcing  their 
respective  local  security  policies. 
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Figure  1.  GENERAL  MODEL 


2.2  DESCRIPTION  OT  PAE,  PAA,  AND  THE  ACCESS  CONTROL 

MODEL 

2.2.1  Peer  Access  Enforcement  (PAE).  The  Peer 
Access  Enforcement  (PAE)  process  is  the  mechanism 
which  enforces  the  access  control  decision.  The 
enforcement  mechanism  comes  into  play  when  data  is 
sent  between  peer  entities.  The  PAE  is  by  necessity 
a  high  integrity  mechanism,  and  is  always  involved 
in  any  secure  exchange  by  virtue  of  acting  as  a 
permission  monitor.  If  the  PDU  is  an  initiator  for 
the  PAA  process  (and  the  creator  of  an  EV)  then  the 
monitor  makes  some  preliminary  checks  (see  Section 
2.2.3)  prior  to  starting  PAA.  If  an  association 
already  exists  then  the  monitor  determines  whether 
or  not  the  labeled  PDU  falls  within  the  set  of 
permissions  represented  by  the  EV  (generated  by 

the  PaA  process).  The  PDU  is  either  permitted 
to  pass  or  not.  If  an  association  does  not 
exist,  the  monitor  will  immediately  drop  into  the 
PAA  process.  The  PAE  is  not  a  negotiation  mechanism 
but  does  perform  two  basic  management  roles; 
association  and  traffic  encryption  key  (TEK) 
management. 

Once  an  association  is  opened  a, id  bound  by  the 
set  of  permissions  represented  by  the  EV,  the 
PAL  monitors  the  exchanges  of  data  to  validate  the 
access  control  decision  parameters  with  each 
PDU.  The  PAE  process  will  maintain  control  over  the 
TEK  for  the  full  extent  of  its  use,  and  will  ensure 
destruction  of  the  TEK  upon  the  end  of  the  crypto¬ 
period.  In  the  event  of  a  recovery  procedure,  the 
PAE  process  will  control  the  TEK  reuse  after 
repeating  the  PAA  processes  for  the  association. 

2.2.2  Peer  Access  Approval  (PAA)-  Peer  Access 

Mppi*Ov'al  13  tnC*  pi'OCt’SS  by  wnlCn  a  $C*nut?r/ i‘t*C  1  p  len  t 

uses  a  particular  implementation  of  the  Access 
Control  model  and  its  rules  to  determine  if  an 
association  should  be  established, 

figure  2  is  a  top  level  diagram  of  the  PAA 
process.  The  PAA  is  divided  into  four  basic  tier 
processes  or  decision  making  steps;  global/ 
partition,  national  RBAC  (Rule-Based  Access  Control), 
local  RBAC,  and  local  IBAC  (Identity-Based  Access 
Control  or  "need  to  know"  access  control).  The 
PAA  tier  processes  are  independent  of  each  other 
and  decisions  to  allow  or  disallow  the  association 
are  determined  and  summed  (logical  AND)  for  the  final 
PAA  decision. 

The  PAA  tier  processes  evaluate  the  elements  of 
both  peers'  identity  and  access  attributes  (as 
presented  in  the  EJRFEIY  certificate)  against  the 
local  authority's  security  policy  requirements. 

The  PAA  process  also  permits  a  security  option 
negotiation  prior  to  establishing  an  EV  for  an 
association.  This  negotiation  could  be  between 
peer  entities  or  through  a  third  party.  Figure  3 
introduces  the  PAA  process  relative  to  the  FIREFLY 
exchange  and  generation  of  the  EV. 

There  is  no  predetermined  order  for  evaluating 
the  lower  three  tiers  o‘  the  process.  In  fact, 
each  is  independent  and  can  occur  first  or  be  omitted 
if  security  policy  dictates.  Tier  one  information 
is  required  for  interpretation  of  some  tier  two 
and  three  data.  The  format  of  the  data,  for  each 
tier,  contained  in  the  FI  REFLY  certificate  will  be 
specified.  How  the  data  is  used  or  interpreted  is 
left  to  the  local  authorities  and  their  specified 
security  policy. 
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The  PAA  process  commences  with  the  FIREFLY 
exchange  and  ends  with  an  access  control  decision  to 
either  allow  the  association  (with  the  appropriate  EV) 
or  disallow  the  association.  The  resultant  F.V  on 
each  end  is  used  to  filter  data  (PAL)  on  a  per 
Protocol  Data  Unit  (PDU)  basis.  The  results  at 
either  end  could  be  different  based  upon  the 
security  policy  of  the  local  end.  A  simple  example 
is  one  where  one  end  employs  L-RBAC  while  the  other 
does  not.  In  this  case  the  resulting  EVs  may  be 
dissimilar. 

2.?. 3  Access  Control  Model  and  Rules.  Before  the 
rules  of  the  modeTare  invoked  (PAA)prel  iminary 
originator  checks  must  be  made  in  the  context  of 
PAF.  For  F-Mail  first  there  is  a  check  to  see  if 
the  intended  recipient  has  posted  public  information. 
In  this  case  the  PAA  process  (application  of  the 
rules)  begins  once  the  sender  has  retrieved  the 
recipient's  public  data.  In  other  cases  a  connection 
is  established  with  the  intended  recipient  in  order 
to  transfer  TIRFFLY  certificates  and  start  the  PAA 
process.  The  preliminary  originator  checks,  in 
non-E-Mail  cases,  begin  when  a  PDU  is  recognized 
by  the  SDNS  component.  As  an  example,  a  check 
is  niade  to  see  if  an  EV  exists  between  tnis  host 
pair  (select  key  against  destination  address  plus 
PAE  rules).  Other  checks  include  some  universal, 

Typo  I  or  Type  II  and  Compromise  Key  l 'St  (CK1  ) 
inspection. 

If  if  has  been  determined  that  a  new  key  is 
needed  for  an  allowable  host  pair  tne  PAA  process 
must  then  be  initiated.  Again  for  E-Mail  the  PAA 
process  scenario  is  somewhat  different.  The  sender 
will  perform  the  PAA  process  first  and  the  recipient 
will  nnl  be  involved  until  he/sne  receives  their  mail. 

The  model  is  valid  for  ISO  Layer  2,  layer  3/4 
boundary,  and  Layer  7  (E-Mail),  in  addition  to 
being  appropriate  in  both  the  Type  I  and  Type  II 
worlds.  An  important  point  regarding  the  model  is 
that  it  is  not  intended  to  dictate  order.  There 
are  disjoint  administrations  whic.n  control  the  access 
information  for  their  own  domain.  When  entities 
wish  to  talk  across  these  administrations  they  need 
to  do  so  in  accordance  with  some  defined  [BAG 
procedure. 

2.3  INDIVIDUAL  TIER  INSCRIPTIONS 

There  are  four  tiers  to  the  Access  Control 
Model.  They  are  briefly  described  in  the  sections 
which  follow. 

2.3.1  Global/Partition.  At  tier  one,  SDNS  access 
control  felines  a  mechanism  which  divides  the 
population  into  disjoint  partitions.  Any  SDNS 
device  with  an  "active"  partition  cannot  talk  to 
any  SDNS  device  with  a  "different"  active  partition 
number.  A  person/host  can  be  a  member  of  only  one 
global  partition  per  each  individual  FIREFLY 
certif icate. 

Once  the  association  has  been  determined  to 
have  the  same  universal,  a  check  at  this  tier  will 
need  to  be  made  against  the  intersection  of  active 
partition  "numbers".  The  results  are  recorded  in 
the  EV  along  with  an  approval  for  the  association 
from  this  tier.  If  the  partition  numbers  do  not 
have  a  match  then  the  process  is  aborted. 


2.3.2  National  Rule  Based  Access  Control  (N-RBAC). 
SDNS  tier  two  access  control  is  dependent  upon  the 
Global/Partition  specified  at  tier  one  and  is 
uniquely  defined  for  that  given  partition. 

Mechanisms  for  separating  information  at  this 

tier  may  or  may  not  be  hierarchical  .  An  example 
of  a  hierarchical  structure  at  this  tier  is  the 
DoD  mandatory  security  policy  of  lop  Secret, 

Secret,  Confidential,  etc.  Along  with  each  of  the 
partitions  is  a  supporting  national  R[IAC  interconnect 
rule  structure.  (Tor  example,  permission  to 
communicate  may  depend  merely  on  the  existence  of  a 
non-null  intersection  between  the  two  peers.) 

Within  a  partition  is  a  single  interpretation  of 
the  national  policy.  Application  of  tier  two  for 
the  Type  II  world  is  left  open  for  further  study. 

The  national  RBAC  evaluation  for  the  hierarchi¬ 
cal  levels  and/or  the  non-hierarchical  categories 
results  in  the  recording  of  the  intersection  in 
the  EV  for  use  in  the  PAE  process.  If  a  peer 
chooses  not  to  enforce  N-RBAC  then  a  "don't  care"  is 
indicated  by  nulling  out  all  N-RBAC  fields  in  that 
peer  entity's  ElRtriY  certificate.  If  a  peer 
chooses  to  enforce  N-P3AC  and  the  intersection  is 
null  then  communication  is  prohibited. 

2.3.3  Local  _Rule  Rased  Acc£SS_Co_ntrol  JL-RBAC). 

SDNS  tier  three  Access  Control  supports  a  mechanism 
to  allow  communities  within  a  partition  to  enforce 
local  rule-based  security  policies,  in  addition 

to  a  National  RBAC.  Local  authorities  establish 
the  policy  for  the  use  and  interpretation  of 
local  RBAC. 

Compartments  partition  those  accessing  data  at 
the  local -RBAC  level  .  These  compartments  fray  be 
combined  with  the  nationally  defined  hierarchical 
security  levels  t.o  determine  access.  As  in  all 
cases  where  a  particular  tier  of  the  model  is 
implemented,  there  must  be  a  non-null  intersection 
of  local -RBAC  compartments  and  appropriate  security 
levels.  If  the  intersection  is  null  then  the 
association  is  disallowed. 

Should  an  intersection  between  peer  entities 
exist  then  the  information  is  placed  in  the  EV  for 
enforcement  during  PAr .  The  per-PDU  information 
(security  lal  'l)  is  then  compared  with  the  infor¬ 
mation  in  the  EV. 

2. 3. 3.1  labeling.  Since  compartments  (L-RBAC)  as 
well  as  categories  (N-RBAC)  could  apply  across  all 
hierarchical  levels  a  potential  ambiguity  exists 
representing  this  information  directly  in  the 
TIRIF1Y  certificate.  If  more  than  one  hierarchical 
bit  is  turned  on  it  is  not  known  whether  all  or 
some  of  the  compartments  pertain  to  each  level. 

Tor  example.  Secret  AB  with  just  Top  Secret  is  a 
possibility  but,  what  could  have  been  meant  is 
Secret  A  and  Top  Secret  B.  We  are  currently 
working  on  understanding  and  documenting  the 
labeling  system  in  use  today.  Simultaneously 
we  are  trying  to  devise  a  way  of  representing 
this  i nforinat ion  in  the  certificate  and  EV 
without  any  ambiguity. 

2.3.4  Local  Identity  Based  Access  Control .  Tier 
four  of  SDNS  Access  Control  allows  a  local 
authority  to  specify  identity  based  controls. 

The  riRFILY  certificate  is  the  only  source  of 
information  for  SDNS  1BAC  decisions.  Some 
communities  may  want  more  1BAC  information  than 
is  contained  in  the  certificate.  If  this  is  the 
case,  there  are  at  least  two  additional  methods 
of  data  exchange.  The  first  approach  requires 
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going  to  a  third  pat  ty  in  realtime  by  one  or  both  of 
the  parties  in  the  association.  An  example  ol  this 
is  using  a  database  external  to  the  SDNS  component 
to  determine  whether  the  SDNS  association  should  he 
allowed.  The  second  approach  is  to  negotiate  the 
MAC  between  the  parties  making  the  association, 
litis  approach  recognizes  that  it  may  be  necessary 
to  bast-  access  control  decisions  on  information  not 
available  within  t tie  rilliri.Y  certificate  and,  as 
such,  may  not  have  the  same  level  ol  integrity. 

3.  LAYI.R  3/A 

3.1  INUWWUCIJON 

At  the  network  layer,  hosts  (which  may,  as  a 
special  case,  be  gateways  to  other  networks  rather 
titan  endpoints  for  traffic)  are  the  peers  between 
which  SDNS  access  control  services  are  applied; 
in  other  words,  the  subjects  and  objects  distinguished 
with  regard  to  differing  access  rights  are  hosts, 
not  processes  or  individual  users  within  hosts. 

The  information  contained  in  the  version  of  FlRiri  Y  ID 
defined  to  identify  a  host  is  appropriate  as  art 
input  to  tii i s  granularity  ot  access  control  decision, 
along  with  layer  3  per-l’DU  message  header  information 
and  control  data  structures  (access  control  tables). 
Subsequent  subsections  will  define  the  fields  within 
a  host  nillTLY  ID,  and  specify  relevant  layer  3 
per-PDU  information.  Once  these  prerequisites  are 
defined,  the  final  subsections  will  discuss  how 
SDNS  components  implement  administration-imposed 
rule-based  and  identity-based  access  control  as 
functions  of  these  inputs. 

3 . 2  ACCESS  CONTROI.  _GRA_miJ.AR ITY  JTOR  LAVE  K_3/4 

3.2.1  Secure  Protocol' A  Ts_P4) .  SI’A  provides 
communication  between  Transport  Service  Access 
Points  (TSAPs);  however,  the  protocol  group  has 
stated  that  they  believe  that  the  access  control 
decisions  would  be  the  same  in  Payer  A  as  in  Layer  3-- 
ttiey  would  just  be  performed  on  different  objects. 

SP4  is  a  proposed  addendum  to  the  connection 
and  connectionless  ISO  Transport  Protocols,  DIS8073 
and  D1SD602.  As  an  addendum,  SP4  is  not  an  integral 
part  of  ISO  TP,  but  is  an  optional  extension  that 
provides  security  services.  The  SP4  addendum 
proposes  a  new  TPDU,  called  Security  Tncapsul ation 
or  St -TPDU ,  that  encapsulates  all  other  TPDUs 
suDsequent  to  protocol  processing  functions.  The 
Sf-TPDl)  conforms  to  the  structure  of  TPDUs  specified 
in  ISO  TP  D1S8073.  The  heading  of  the  St -TPDU 
includes  a  variable  length  label  field  that  can 
be  used  for  Access  Control  decisions. 

3.2.2  Secure  Protocol  3  (SP3).  The  SP3  proposal 
provides  authentication  "of  NSAPs  instead  of  TSAPs. 

SP3  supports  both  RDAC  and  1RAC  decisions.  SP3 

is  not  expected  to  have  an  impact  on  the  surrounding 
protocols,  so  limitations  of  the  labeling  by  the 
other  protocols  is  not  a  factor.  SP3  provides  a 
security  label  that  is  independent  of  the  underlying 
network  protocol.  The  TPDU  security  label  may  be 
mapped  into  the  ST3  security  label  if  access  is 
authorized . 

3.3  I  n_PI  ELD:  DfJ  I NJ  T I  ON  .AND  USAGF 

The  fl REPLY  ID  MUST  "provide"  the  following 
information: 

o  The  security  levels  and  fields  to  support 
the  model  in  Section  2  of  this  document. 

o  Environmental  and  certification  information 
for  RDAC  (if  enforced). 

o  A  unique  identity  for  authentication. 


3.4  I’lR-PDU  INI  0RMA1  ION :  DPI  INITKIN  AND  USAGL 

Path  Sl’3  and  SIM  I’UU  includes  a  sccuri ty- 1  abel 
field  and  information  that  identifies  the 
cryptographic  association.  An  integrity  mechanism 
protects  all  the  Access  Control  information.  The 
label  is  used  to  enforce  a  check  ot  the  security 
level  of  the  data  against  the  security  range 
of  the  cryptographic  association. 

3 .  b  UUI.I  ItASI  Il  ACCI  SS  CONMOl 

When  National  RDAC  is  enforced,  the  intersection 
of  the  allowable  security  levels  for  non-hierarchical 
compartments  for  the  connection  must  not  be  null. 

Tor  I -RDAC  there  must  bo  a  release  category  in 
common  between  the  two  peer  entities  (if  release 
categories  are  used). 

The  following  rules  must  be  followed  to  allow 
connection  of  hosts  with  different  levels  of 
certification  and  different  classes  of  users  and 
to  prevent  the  cascading  problem. 

o  Hosts  can  be  interconnected  as  long  as  the 
environment  of  the  host  with  the  highest 
level  of  trust  is  maintained.  (It  is 
a  superset  of  the  other  host's  level  of 
trust. ) 

o  If  the  two  hosts  are  not  accredited  at 
at  the  same  level,  the  higher  level 
host  must  treat  all  data  transmitted 
as  the  highest  level  of  data  that  the 
lower  level  host  can  contain,  or  associate 
a  level  of  trust  with  each  packet  of 
data.  Note  that  this  requires  a  trusted 
guard  (probubly  human)  to  verify  and 
perform  the  write-dowr  back  to  the 
correct  level. 

3.6  1DI Jim Y  .BASED  ACCESS  CONTROL,  (MAC) 

Access  Control  consists  of  two  distinct 
steps:  1)  authentication,  and  2)  authorization. 

The  I'lREfTY  ID  and  the  PAA  protocol  provide 
authentication.  The  PAf  ensures  that  the 
authentication  is  maintained  for  the  entire 
association.  The  Source  Address/Destination 
Address  in  the  Protocol  Data  Unit  (PDU)  and  the 
cryptographic  separation  provided  by  the  algorithms 
are  sufficient  to  maintain  authentication  at  this 
level.  Authorization  can  be  done  in  many  different 
ways  in  SDNS.  Once  the  identity  is  provided  by 
the  PAA  exchange,  this  identity  can  be  used  to 
grant,  rights  or  privileges  to  the  host .  All 
rights  granted  at  this  stage  must  be  subject  to  the 
constraints  of  the  RBAC  or  National  Policies  as 
mentioned. 

4.  LAYER  7  ELECTRONIC  MAIL 
4.1  INTRODUCTION 

As  a  result  of  the  overall  scope  of  SDNS  Phase  I, 
the  Access  Control  issues  and  mechanisms  discussed 
in  this  section  relate  to  electronic  mail  and  are 
not  necessarily  applicable  to  protection  of  other 
application  layer  services  (e.g.,  ETAM).  Different 
application  layer  services  may  require  different 
Access  Control  services  and  mechanisms.  In 
particular,  the  store  and  forward  delivery  character¬ 
istic  of  electronic  mail  introduces  a  number  of 
special  issues  which  do  not  apply  to  an  environment 
in  which  peer  entities  communicate  directly  in  real- 
time.  On  the  other  hand,  certain  characteristics  and 
issues  discussed  here  are  likely  to  be  relevant  to 
other  application  layer  SDNS  services  addressed  in 
the  future:  the  placement  of  application  layer 
peers  at  the  top  of  the  layered  protocol  hierarchy 
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virtually  dictates  that  application  layer  SDNS 
functions  will  be  integrated  within  a  host  computer 
or  within  a  peripheral  associated  with  a  host 
computer,  not  in  a  device  interposed  on  the 
computer's  network  interface  connection.  In  order 
to  support  application  layer  SDNS  functions,  users 
must  rely  on  processing  performed  within  hosts. 

The  access  control  services  discussed  here  ore 
relevant  only  to  the  protection  of  electronic  mail 
traffic  between  user  entities.  They  are  not 
applicable  to  the  protection  of  control  traffic 
passed  between  the  internal  application  layer  peer 
entities  which  exchange  control  traffic  among  SDNS 
components ,  or  to  the  control  traffic  passed  between 
SDNS  component  internal  application  layer  entities 
and  the  Key  Management  System  (KMS).  Moreover, 
they  arc  not  applicable  to  control  of  access  from 
an  originator  SDNS  component  to  an  intermediate 
black  network  component  such  as  a  mail  or  directory 
server.  Since  such  controls  would  not  involve 
peer  SDNS  components  at  both  ends  of  a  path,  they 
are  outside  the  SDNS  puivicw. 

4.2  ACCESS  CONTROL  AND  ELECTRONIC  MAI  I 

At  the  application  layer,  the' peers  between 
which  SDNS  access  control  services  are  appl ied  are 
User  Agent  (UA)  processes,  corresponding  to 
individual  users,  within  end  system  hosts.  SDNS 
functions  will  be  integrated  within  the  UAs ,  which 
are  instantiated  to  support  identified  individual 
users.  It  is  reasonable  and  consistent,  therefoic, 
to  provide  security  services  at  per-user  granularity. 
The  information  contained  in  the  version  of  1IRITLY 
ID  defined  to  identify  a  user/entity  within  a  host 
is  appropriate  as  an  input  t.o  this  granularity  of 
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message  header  information  and  control  data 
structures  (access  control  tables,  possibly 
supported  by  servers).  A  subsequent  subsection  will 
specify  relevant  Layer  7  per-PDIl  information,  and 
will  discuss  how  control  data  structures  are  used. 

In  composition,  these  mechanisms  allow  SDNS 
components  to  implement  admini strat ion -imposed 
rule-based  access  control  (RhAC)  and  identity-based 
access  control  ( 1 UAC ) . 

4.2.1  Types  of  _Acccss  Control  Policies.  Identity- 
based,  admi  nut  ration -imposed  L-Mall  'access  controls 
incorporated  in  application  layers  SDNS  modules  can 
constrain  mail  dataflows  in  accordance  with 
locally-defined  policies  (e.g.,  "who  is  user  A 
allowed  to  send  mail  to?")  Rule-based  policies  can 
also  be  appropriate  at  the  F-Mail  application  layer. 
In  a  multi-level  host  with  appropriate  inter-user 
segregation  mechanisms,  the  differing  access 
rights  of  users  witli  different  clearances  (as 
defined  by  the  users'  TlRni.Y  IDs)  can  he  distin¬ 
guished  by  application  layer  SDNS  modules.  A 
particular  SDNS  instantiation  may  perform  neither, 
either,  or  both  types  of  controls;  where  identity- 
based  and  rule-based  controls  are  active,  both 

sets  of  checks  must  succeed  before  access  is  granted. 

4.2.2  Impact  ot  Store-and-forward  Delivery.  The 
store-and-forward  delivery  mode  characterist ic  of 
D-Mail  is  incompatible  witli  access  control 
mechanisms  which  depend  on  a  second  exchange 
after  the  initial  peer-peer  exchange  of  TIRiriY 
quantities.  (When  network  or  transport  layer 

SDNS  services  are  employed  in  addition  to  application 
layer  E-Mail  services,  post-EIREILY  exchanges  may 
occur  between  the  lower  layer  peers  protecting 
segments  of  the  store-and-forward  path  supporting 
E-Mail  transfer,  but  this  is  independent  of  the 
application  layer  mechanisms  discussed  in  this 


section.)  Originator  and  recipient  UAs  do  not,  in 
general,  coiiniunicate  in  realtime;  as  a  result,  the 
information  contained  in  a  recipient's  certificate 
(as  posted  on  a  server  or  bulletin  board  system)  must 
Ire  sufficient  to  allow  an  originator  to  perforin  any 
desired  access  control  checks  . 

4.3  ID  riJJD:  DI1INITI ON  ANDJISAGI 

It  is  appropriate  to"  consider  the  means  by 
which  user's  arc  identified  within  X.400  mail,  as 
identifying  fields  in  X.400  message  headings  inns' 
be  associated  with  (TRULY  ID  fields.  X.420  notes 
that  I -Mail  users  may  he  identified  in  two  ways: 
witli  an  Oriy  inator/Recipient  (0/R)  name  (a  construct 
formally  defined  in  X.411)  or  with  a  free-form 
name;  for  universal  applicability  in  SDNS,  use 
ot  tire  0/R  name  is  assumed.  Three  variant  forms 
of  0/R  names  are  defined,  but  the  latter  two  arc 
intended  for  special  purposes  (support  for  X.121 
addressing  or  Telex  interoperability),  and  the 
first  variant  is  clearly  the  appropriate  choice  for 
consideration  by  SDNS. 

lor  SDNS  purposes,  it  is  proposed  that  a 
user's  ID  as  represented  in  a  certificate  contain 
tire  following  0/R  name  components:  Dountry  Name, 
Administration  Domain  Name,  Organization  Name, 
Organizational  Unit  Names  (this  component  may  be 
null  if  Organizational  Unit  Names  are  not  used 
within  the  particular  Organization) ,  and  Personal 
Name.  Note  that  this  identifies  a  user  in  terms 
of  organizational  affiliation,  riot  mailbox  address, 
and  hence  does  not  preclude  user  mobility. 

4.4  l-l  It-pptl  ]NJ  ORMAUON :  Dll  I N  IT  I  ON  AND  USAC.L 

"The  value  of  the  CCITT’-Vpeci  f  ied  Sensitivity 

inu  i_,it  ion  heading  field  is  resiricU’d  to  one  ui 
three  possibilities  (Personal,  Private,  and 
Company  Confidential).  This  set  of  options 
does  not  correspond  appropriately  to  the  hierarchic 
levels  enforced  by  SDNS  RBAC  in  a  Type  I  environment. 
Therefore  the  SDNS  proposed  changes  to  X.420  include 
an  additional  security  label  field. 

4 . 5  RUI  I  HAST H  ACC l  SS  CONI  R01. 

4.3.1  Inter-User  RDAC  Issues .  On  initial  consider¬ 
ation,  "RBAC  enforcement  Tor  T -Mail  appears  simpler 
than  RBAC  enforcement  for  host-level  peers  at  the 
network  or  transport  layers,  since  no  interconnect 
rules  are  needed  to  constrain  communications  between 
pairs  of  human  users,  faclr  user-  is  "trusted"  to 
process  and  correctly  segregate  information  at  any 
level  up  to  and  including  his/her  hignest  clearance. 
The  absence  of  interconnect  rules  between  human 
users  does  not  imply  that  no  RBAC  mechanisms  are 
appropriate.  While  it  is  legitimate  for  a  TS- 
cleared  user  to  send  a  message  to  a  Secret-cleared 
user,  such  a  message  should  not  contain  any 
informal  iori  designated  witli  sensitivity  higher  than 
Secret.  A  sending  SDNS  UA  can  collect  clearance 
information  from  certificates  of  a  message's 
designated  recipients,  can  compute  the  intersection 
with  the  sender's  privileges,  and  can  display 
that  information  to  a  sending  user.  (Note,  however, 
if  implemented  this  way,  this  function  requires 
that  recipient's  certificates  be  cached  or  collected 
in  realtime.) 

further,  tire  UA  can  verify  the  relation  hot  ween 
the  level  provided  in  the  certificate  and  the 
level  at  which  the  UA  process  is  executing,  for 
example,  a  single-level  UA  running  at  the  TS  level 
should  not  transmit  mail  to  a  recipient  whose 
certificate  indicates  Secret  or  lower  clearance, 
although  a  multi-level  UA  spanning  the  TS  and 
Secret  levels  could  transmit  Secret  mail  to  such 
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oflicial  channels  and  will  tie  delivered  to  a 
CFE  either  electronical  ]  y ,  over  the  network, 
or  physically  in  a  Data  Key  device.  This 
CFE-tO-CFE  FIREFLY  exchange  accomplishes 
decentralized  traffic  key  generation  and 
access  authorization;  allowing  continued 
secure  operation  of  the  network  during  the 
contingency  mode  when  a  central 
administrative/control  node  is  out-of- 
service  or  in  unreachable.  Each  individual 
CFE  in  the  system  will  "keep  book"  on  up  to 
1000  permitted  crypto-connections  so  that  i'. 
need  not  go  to  the  CCP  lor  permission,  or  it 
need  not  execute  a  CFE-CFE  FIREFLY  exchange, 
for  connections  previously  authorized  during 
the  same  crypto  period. 

Access  Control -  CANFWARE1 s  Trusted  Computing 
Base  rigorously  enforces  Mandatory  Access 
Control  (MAC)  to  ensure  that  data  passed 
from  hosr-to-host  will  ve  within  the 
security  range,  and  compliant  to  the 
compa rtmenta  1  i zation  permitted,  for  that 
particular  host-pair  communication  .  MAC 
credentials  will  be  included  in  each  CFF's 
FIREFLY  vector  set  and  will  be  reciprocally 
transferred  during  the  CFE-to-CFE  FIREFLY 
exchange  .  MAC  will  support  8  security 
levels  and  over  ICC  compartment'..  The  MACs 
will  be  enforced  by  the  CFE's,  be  operative 
in  both  the  normal  and  contingency  modes, 
and  can  not  be  overridden  .  Discretionary 
Access  Control  (DAC)  privileges  will  be 
managed  and  distributed  by  the  CCP.  DAC  may 
further  constrain  MAC  but  may  not  upgrade 
the  mandatory  limits.  DAC  will  specify  which 
CFE  pairs  can  intercommunicate  and  which 
pairs  cannot  .  Again  enforcement  is  a  CFE 
responsibility.  Each  CFE  will  maintain  an 
include/exclude  list  of  possible 

connections.  The  CCP  will  update  the  1 1st 
when  appropriate.  Only  when  an  addressee  is 
not  cn  either  list  will  a  cfl  need  to 
request  permission  to  open  a  connection.  in 
a  contingency  situation  (when  the  CCP  or  its 
alternate  is  unreachaole)  the  CFE  ’ill 
comply  with  the  resident  include/exciudo 
lint;  r-  connections  (those  with  no  list 
entry'  l  \, .  permitted  but  tagged  for 

later  /rting  to  the  CCP  which  might 

ex  ■  •  revoke  intercommunication 

<  -  behavior  is  also  a  MAC 

r  CAREWARE  will  authenticate  the 

t  ■  '  'anr.for  of  security  labels  and 

th  -  source  addresses. 

Monitor.’  n«  o.id  Control-  The  CFE’s  and  CCP's 
cooperatively  capture  an  G ..ensivc  log  of 
security  events  (security  range  violations, 
illegal  connection  attempts,  alarm 
occurrences,  etc.)  .  CCP's  maintain  a 

comprehensive  data  base  of  those  system 
events  to  provide  an  audit  trail  of 
attempted  or  inadvertent  security 

violations  .  For  CFE's  within  its  domain, 
tlu;  CCP  can  request  health/status  infor- 
niation  anti  can  initiate  various  security  and 
communioati jns  tests  («idrm  tests,  loop-back 
tests,  etc.)  The  CCP  operator  establishes 
thresholds  for  reporting  system  and  security 
event  oUdit  data  .  The  CCP  operator  can 
assign  configuration  parameters  (data  rates, 
protocol  options,  RS-449  options,  etc.)  and 
cause  them,  to  be  downline  loaded  to  its 
community  of  CFE's  .  Fully  secure  inter¬ 
domain  communications  ais  managed  by 
CCP-t  o-CCP  coordination  .  A  major 

responsibility  of  the  CCP  is  the  maintenance 


(establishment,  updating)  and  distribution 
of  its  CFE's  network  address/  translation 
database . 

Communications  Interfaces-  The  CFE  is 
normally  installed  in  a  network  access 
communications  link  between  a  host  computer 
and  a  packet  switch  (also  known  as  an 
Interface  Message  Processor,  or  simply  IMP) . 
The  host  is  characterized  as  a  data  terminal 
equipment  (DTE),  the  IMP  as  a  data  circuit 
terminating  equipment  (DCE)  .  The  CFE's 
physical  interfaces  conform  to  RS-449  and 
MIL-S'-'D-IBB— 114A .  The  link  protocol  (level 
2)  is  LAPB  .  The  network  access  protocol 
(level  3)  is  the  DDN  "standard  Service" 
version  of  X.25.  Over  ..25  the  CFE  will 
support  Internet  Protocol  (IP,  MIL  STD 

1777)  .  The  above  "external"  protocol  suite 
is  implemented  on  both  the  Red  and  Black 
sides  of  the  CFE  .  In  addition,  CANEWARE 
execute.s  other  "internal"  protocols  tc 
accommodate  its  own  Host  -CFE,  CFE-CFE,  and 
CFF-CCP  transactions.  These  include  end-to- 
end  encryption  protocols,  status  messages, 
configuration  data,  etc. 


SDN  IS  Relat]  ershius-  Secure  Data  Network 
System  (SDNS)  is  a  current  NSA  sponsored 
program  with  the  objective  of  developing  and 
promoting  security  architecture  standards 
for  a  wide  variety  of  data  communications, 
particularly  packet  switched  networks 
(PSN's)  and  local  area  networks  (LAN's).  It 
is  expected  that  the  resulting  standards  and 
technology  will  dominate  future  secure  data 
network  systems  and  equipment  .  SDNS 
compatibility/  interoperability  is  a  program 
objective  .  It  is  a  design  goal  of  CANEWARE 
to  comply  with  the  evolving  standards  of 
SDNS  .  If  CANEWARE’s  leading  schedule 
disallows  SDN'S  interoperability  for  the 
initial  CFE  equipment  the  design  will 
provide  for  lacel  accommodation  via  software 
update  .  An  SDNS  i elated  effort  is  the 
development  cf  a  Key  Management.  Center 
(KMC)  .  Tl.e  KMC  will  be  established  and 
operated  by  14SA  to  provide  FIRETLY  keying 
material  for  the  o-:.ta  world.  CANEWARE  will 
use  this  facility  to  obtain  its  FIREFLY  key 
vectors.  Irus,  will  exploit  the  economies - 
of-scaie  achievable  by  such  a  "public 
utility"  approach  to  key  management  vis-a- 
vis  the  establishment  or  key  distribution 
centers  dedicated  to  individual  communities 
of  CANEWARE  users. 


5_.0  PERFORMANCE  - 

CANEWARE  will  provide  "high  perforin-ance" 
security  services  to  eliminate  encryption 
choke  points  ip  the  network  .  The  basic 
performance  determining  parameters  for 
X.25  operations  are: 

Input/Output  Rate  -  to  1.544  Mbs 

Data  Throughput  -  >750  Kbs 

Packet  Rate  -130  Packots/soc 

Processing  Delay  -  <15  ms 

Note  that  the  above  parameters  are  tor  full- 
duplex  operation;  the  equipment  can  sustain 
these  rate:;  while  simultaneous] /  processing 
traffic  in  both  directions  .  processing 


Fir.  1 .  CANEWARE  Front  End  (Stock  Diagram 


techniques  are  designed  to  enhance  perfor¬ 
mance  .  For  example,  permanent  network  and 
cryptographic  connections  are  supported  for 
critical  and  frequent  addressees  to  reduce 
set-up  time. 


6  .0  IMPLEMENTATION  and  OPERATION  -FIGURE  1 
is  a  block  diagram  of  the  CFE  hardware  . 
Identical  RED  ana  black  side  Protocol 
Processors  each  incorporate  an  MC68020  32- 
bit  microprocessor  and  supporting 
electronics  .  The  Crypto-Processor ' s  main 
functions  are  encryption,  decryption,  key 
variable  storage,  FIREFLY  operations,  and 
alarms  .  The  Crypto-Frocessor  uses  several 
custom  VLSI  chips  .  The  Network/Host  I/O 
hardware  is  also  identical  on  both  the  RED 
and  BLACK  sides  (software  is  different)  . 
The  principal  I/O  tasks  are  data  flow- 
control  at  the  external  interfaces  and 
to/ from  the  crypto-processor  .  These 

functions  are  performed  by  a  custom  VLSI 
multi-cnanrel  DMA  controller,  specialized 
physical  and  link  level  I/O  chips,  and 
support  electronics.  The  equipment  includes 
a  front  panel  key  pad  and  an  80-charactcr 
display,  to  facilitate  a  menu-driven 
operator  interface  .  CANEWARE's  custom 
software  includes  approximate  1 y  4SK  lines  of 
code  for  the  CFE  and  20K  lines  of  code  for 
the  CCF  ,  The  CCP  also  incorporates 

commercial  opera'  ;ng  system  ana  data  base 
management  software  .  Subscribe!  hosts  are 
"trusted"  to  properly  label  all  outgoing 
data  with  its  security  classification.  This 
implies  hosts  have  a  COMPUSEC  rating 
commensurate  with  the  range  of  data  that 
they  are  handling.  This  label  is  placed  in 
the  Internet  Protocol  Security  Option  (IPSO) 
field  of  the  datagram.  The  host  is  expected 
to  provide  a  reliable  transport  protocol 
above  IP  to  assure  that  host-to-host  djt-a  is 
reliably  delivered. 
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7 _ ;_0_  SUMMARY  OF  CANEWARE  FEATURES  "The 

following  is  a  summary  listing  of  the  of  the 
principal  features  of  tne  CANEWARE  system: 

♦Packet  Switched  Network  Security 

*Hiqh  Speed  Architecture 
-Throughput  >730  Kbs,  F/D 
-130  packcts/sec,  F/D 

♦  DOD  IP/X.25  Protocol  Suite 

♦Access  Control 

•Extensive  Built-In  Test 

♦Configurable  1/0,  Communications, 
and  Security  options 

♦Cryptographic  Data  Protection 

♦Multi-Level  Security  ( B2  COMPUSEC) 

♦State-of-the-Art  FIREFLY  Key 
Management 

8.0  PROGRAM  STATUS/FUTURE  - 

The  CANEWARE  program  is  targeted  at  1990 
production  of  operational  equipment  .  The 
development  schedule  is: 

CFE 

Prototype  Available 
First  E-model  CFE 
- Har dwarc/Sof tware 

Integration  -August 

CCP 

Uardwar e/Soft ware 
Integration  -August  1988 

SYSTEM 

-  CIE/CCP  Integration  -Cct.  1988 

-  System  Verif ication  -March  1939 

FUTURE 

-  In  the  future  it  is  expected  that  the 
CANEWARE  "product  line"  will  be  expanded 
to  include;  GATEWAYS,  LAN  ENCRYPTORS,  and 
TERMINAL  ACCESS  EQUIPMENT. 


988 

1  988 

1988 
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Abstract 

A  new  information  flow  tool  for  the  Ina  Jo  specification 
language  is  described.  The  flow  tool  is  built  into  the  Ina 
Jo  language  processor,  and  generates  flow  conjectures 
that  are  proven  with  the  Interactive  Theorem  Provcr. 

The  flow  tool  is  being  used  for  covert  channel  analysis  in 
ongoing  A I  development  projeecs. 

1.  Introduction  and  Overview 

The  Formal  Development  Method  (FDM)  includes  the  Ina 
Jo T"  formal  specification  language,  a  processor  for  the  Ina  Jo 
language,  and  the  Interactive  Theorem  Prover  (1TP),  for  prov¬ 
ing  theorems  generated  by  the  Ina  Jo  language  processor.  For 
more  information  about  F'DM  see  [6),  11 1|.  1 12|.  and  1131- 

lna  Flo,  an  information  flow  tool  for  the  Ina  Jo 
specification  language,  aids  covert  channel  analysis  of  mul¬ 
tilevel  secure  (MLS)  systems.  Ina  Flo  is  built  into  the  Ina  Jo 
language  processor,  and  is  invoked  either  with  a  command-line 
flag  to  the  Ina  Jo  processor,  or  by  including  a  flag  in  the 
specification.  Ina  Flo  accepts  the  entire  Ina  Jo  language, 
although  certain  features  of  the  Ina  Jo  language  are  not  amen¬ 
able  to  automated  flow  analysis.  These  features  arc  discussed 
in  section  2. 1. 

Ina  Flo  actually  includes  two  flow  tools.  One,  henceforth 
called  MIS,  is  similai  to  those  described  in  jS)  and  |l()j.  and 
also  has  similarities  to  Mitre's  Flow  Table  Generator  |H|.  The 
other  implements  the  Shared  Resource  Main*  approach  J 7 ]. 
Only  the  MIS  tool  is  discussed  in  ibis  paper. 

We  believe  In-  Flo  is  unique  among  automated  flow  tools 
for  its  scope:  it  accepts  the  enure  Ina  Jo  language,  including 
nondetertnimstic  specifications;  it  accepts  arbitrary  (lattice- 
based)  security  policies,  including  variable  labels;  it  provides 
varying  levels  of  support,  depending  on  completeness  of  the 
security  policy  specification 

Information  flow-  in  Ina  Jo  specifications  is  discussed  in 
section  2.  Section  3  presents  requirements  and  guidelines  for 
the  use  of  MIS  Section  4  describes  a  preprocessor  for  Ina  Flo 
that  helps  in  writing  deterministic  specifications.  The  Appendix 
summarizes  the  parts  of  the  Ina  Jo  language  used  in  this  paper. 


and  contains  an  example  demonst,  suing  MLS. 

2.  Information  Flow  in  Ina  Jo  Specifications 

The  term  "information  flow"  applied  to  a  state  machine 
model  refers  to  flow  of  information  from  one  entity  in  some 
state  to  another  (possibly  the  same)  entity  in  a  subsequent  state. 
In  the  Ina  Jo  language  the  entities  from  which  information  may 
flow  are  variables  and  formal  parameters  of  transforms.  The 
entities  to  which  information  m;.y  Row  are  variables.  State 
transitions  are  modeled  by  transforms. 

An  imprecise  statement  of  the  definition  of  information 
flow  used  in  MLS  is  as  follows: 

(♦)  If  the  new  value  of  y  depends  on  the  old  value  of  x  then 
information  flows  from  x  to  y  (written  x  -»  y). 

It  is  assumed  that  y  is  a  declared  variable.  Its  new  value  is  the 
value  it  has  after  the  effect  of  a  transform.  It  is  further  assumed 
that  x  is  either  a  variable  or  a  transform  formal  parameter 
(transform  fomtal  parameters  are  treated  as  read-only  vari¬ 
ables).  The  old  value  of  x  is  the  value  it  had  before  the 
transform.  The  meaning  of  the  phrase  "depends  on”  is  deter¬ 
mined  by  the  semantics  of  the  specification  language. 

The  lattice  model  12]  is  built  into  MIS,  to  the  extent  that 
MIS  assumes  (and  forces  the  user  to  prove)  that  the  security 
policy  included  in  a  specification  is  a  lattice.  Therefore,  the  fol¬ 
lowing  rule  may  be  used  for  determining  security 

(**)  A  flow  x  -»  y  is  secure  if  and  only  if  M!.S_Labcl(y ) 
dominates  MLS._I-abel(x). 

In  other  words,  information  may  securely  flow  to  entities  at  the 
same  or  higher  levels,  but  not  to  entities  at  lower  (or  incompar¬ 
able)  levels.  This  rule  introduces  the  MLS_ Label  of  a  vari 
able,  which  represents  the  variable’s  sensitivity  label,  and  the 
relation  dominates,  which  represents  an  arbitrary  user- 
specified  partial  order  relation  on  sensitivity  labels.  A  more 
rigorous  statement  of  the  flow  model  in  Ina  Flo  is  in  prepara¬ 
tion. 
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2.1.  Nondcternimism  and  incompleteness 

Ic  is  not  always  possible  to  determine  precise  dependencies 
between  old  and  new  values  of  variables,  because  Ina  Jo 
specifications  may  be  nondeterministic.  I-'or  example,  if  tbe 
effect  of  a  transform  is  N"A  -  N"B  then  A  and  B  have  the 
same  new  value,  but  nothing  is  known  about  this  value,  other 
than  its  type.  Every  state  variable  might  be  referenced  in  deriv¬ 
ing  this  new  value.  Therefore,  it  may  be  possible  to  infer  some¬ 
thing  about  the  old  value  of  any  variable  from  the  new  value  of 
A  (or  B),  and  thus  there  are  potential  (lows  from  every  variable 
to  A  and  to  B. 

Another  example  of  a  nondeterministic  effect  is:  ri"X  - 
1  I  N"X  =  2.  Here  the  new  value  of  X  is  certainly  1  or 

2,  but  the  specification  does  not  tell  us  which,  nor  how  the 
choice  is  made.  Again  any  state  variable  may  be  referenced  in 
deciding  whether  the  new  value  of  X  is  1  or  2,  so  there  arc 
potential  flows  from  every  variable  to  X. 

In  our  limited  experience  with  the  flow  tool  to  date  we 
have  not  found  it  useful  to  generate  flow  conjectures  for 
transforms  with  nondeterministic  flows.  Therefore,  MLS  pro 
duces  a  false  conjecture  for  transforms  that  contain  nondeter- 
ministic  flows,  along  with  a  list  of  the  nondeterministic  flows. 
We  plan  to  make  this  behavior  optional,  since  there  may  be 
cases  in  which  nondeterministic  flows  can  be  proven  secure, 
e.g.,  when  all  nondeterministic  flows  are  to  System  High.  In 
gcucial,  the  flow  looi  user  wiii  iikciy  find  u  more  useful  to  defer 
covert  channel  analysis  to  a  lower  (deterministic)  level  of 
specification.  Nondeterminism  is  discussed  further  in  section  4. 

Another  difliculty  in  trying  to  do  information  flow  analysis 
of  Ina  Jo  specifications  is  that  they  need  not  be  functionally 
complete.  That  is,  an  Ina  Jo  specification  need  not  represent 
every  operation  that  may  be  performed  by  an  implementation. 
Sec  part  1V(C)  of  1 1 1  for  a  discussion  of  this  point.  Ina  Mo 
obviously  cannot  find  flows  in  operations  that  are  not  specified 
as  transforms,  so  use  of  Ina  Ho  on  incomplete  specifications  is 
not  advisable. 

3.  The  MLS  Flow  Tool 

MIS  generates  conjectures  (one  for  each  transform)  that,  if 
true,  guarantee  that  no  storage  channels  are  in  the  specified  sys¬ 
tem.  Realistically,  some  flow  conjectures  will  usually  not  be 
provable,  these  represent  potential  covert  channels  for  which 
manual  analysis  will  be  necessary.  Even  if  all  the  conjectures 
are  true,  there  is  no  assurance  that  an  implementation  will  not 
have  storage  channels,  unless  the  code  is  formally  shown  to 
perform  all  and  only  the  actions  specified  as  Ina  Jo  transforms. 

3.L  Specifying  a  Security  Policy 

hollowing  Denning  |2|,  an  information  flow  policy  is 
defired  by  a  lattice  (.Sc.’,  dominates),  where  SC  is  a  set  of  seeu 
rity  classes,  and  dominates  is  a  binary  relation  partially  ordering 
the  classes  of  SC.  f  rom  this  definition  it  follows  immediately 
that  dominates  must  be  reflexive,  transitive  and  anti -symmetric. 


and  that  the  set  SC  must  contain  a  least  upper  bound  and  a 
greatest  lower  bound. 

To  make  this  definition  practical,  users  must  be  provided 
the  means  to  specify  security  policies.  For  MIS  this  is  done  by 
building  into  the  specification  language  the  capability  to 
specify: 

(1 )  a  set  of  sensitivity  labe.s  (security  classes), 

(2)  an  ordering  iclation  for  these  labels, 

(3)  a  label  associated  with  each  variable  and  transform. 

Tbe  mechanisms  for  doing  these  things  are  described  in  the  fol¬ 
lowing  subsections.  See  |4|  for  details. 

3.1.1.  Declaring  Labels 

Any  declared  constant  or  variable  may  be  used  as  a  label, 
with  the  restriction  that  each  label  must  have  type 
MI.S_I,abe )  .  This  type  name  is  built  into  MLS,  but  it  is  not 
built  into  the  Ina  Jo  processor.  Therefore  the  user  must  declare 
MI.S_Label  explicitly.  MLS_Labe)  may  be  any 
unspecified  or  specified  type.  Examples  of  valid  declarations  of 
MI.S_l.abol  arc 

TYPE  Ml.S_I,abe) 

TYPE  MLS_Labc)  «  (U,  C,  S,  T5) 

T  i  r.  Class  ■  (u,  C,  3,  t:.i. 

Category, 

Catfc-joi  i  es  =  Set  of  Category, 
Mi.S_l.abel  =•  Class  ><  Categories. 

Hie  first  example  leaves  Mi,:;_J,abc)  completely  unspecified; 
it  will  presumably  be  specified  more  fully  either  with  axioms  or 
at  a  lower  level  of  specification.  The  second  example  declares 
Ml, S  Label  to  be  an  enumerated  type  with  four  values.  The 
third  example  matches  the  usual  notion  of  security  labels  in  the 
paper  world. 

3.1.2.  Ordering  the  Labels 

Hie  user  must  specify  the  relation  dom  i  tint  or;  if  MIS  is 
to  generate  flow  conjectures;  otherwise  MIS  generates  lists  of 
flows,  as  in  |K|.  Dominates  may  be  specilied  partially  or 
fully  with  axioms.  However,  the  specification  must  include 
enough  information  to  prove  the  following  conjectures,  which 
ensure  Wat  the  specification’s  security  policy  is  a  lattice: 


(1) 

A" 

lev: 

MI.S  _ 

labe  1 

(  dom  i  n.it  » * 

r.  ( r. 

ysll i ,  lev) 

(?) 

A" 

1  ev : 

I-df-el 

(  doiD j  not  «.* 

Ml 

ev,  f.  y I.o  ) 

(  3) 

A" 

lev: 

mi 

Label 

(  domi  rial  <.* 

Ml 

e  v ,  1  o  v )  ) 

(1 ) 

A" 

lev! 

,  lev,' 

:  MLS 

Label  ( 

d. >m i  not  C5  (  lev]  ,  h  v?l 
t>  duminat  cs  ( lev?,  levl ) 

— >  li-vl  -  lev?  ) 

(',)  A"  J  evl ,  1  ev? ,  1  f  v  3  :  MLS  label  ( 
dom i not  i;s  (  1  nv  1 ,  1 . ■  v? ) 
t,  dominat  os  ( lev?,  lev  3) 

— >  domi  n.jt  cs  (  lev]  ,  1  ev  3)  ) 


(1)  asserts  that  SysHi  is  the  least  upper  bound  of  the  set 
defined  by  the  type  MLS  Label,  and  (2)  asserts  that  Syol.o 
is  the  corresponding  greatest  lower  bound.  The  labels  SysHi 
and  Sy  sLo  arc  built  into  MLS ,  but  are  not  built  into  the  Ina  Jo 
processor,  so  they  must  be  explicitly  dcclated  as  constants  (or 
zero-state  definitions)  of  type  MLS_Label.  (3)  asserts  that 
dominates  is  reflexive,  (4)  that  it  is  anti -symmetric,  and  (5) 
that  it  is  transitive.  The  five  conjectures  are  built  into  MLS  as 
assumptions',  but  they  are  not  built  into  the  ITP  Examples  fol¬ 
low; 

TYPE  MI,S_Label 

CONSTANT  SysHi,  SysLo:  MI,S_Label, 

dominates (MLS_Label, MLS_Label) : boolean 

This  is  the  minimum  that  must  be  specified  if  you  want  MLS  to 
produce  flow  conjectures.  The  type  MLS_Labol  is 
unspecified,  as  are  labels  SysHi  and  Sy.sLo  and  the  relation 
dominates.  The  conjectures  (1)~(5)  will  usually  not  be 
provable  unless  they  are  included  as  axioms  in  the  specification. 
TYPE  MLS  Label  -  (U,  C,  S,  TS) 

DEFINE  SysHi  —  TS, 

SysLo  ==  U, 

dominates ( 1 1, 1 2 : MLS_Labei )  -=  11  >=  12 

Syslt  i  and  Sy.sLo  are  defined  to  be  the  greatest  and  least  ele¬ 
ment,  respectively,  of  type  MLS_Label ,  and  dominates  is 
defined  by  the  “>="  operator.  Since  the  ITP  knows  that 
is  a  partial  order,  conjectures  (1) — (5)  will  be  provable  from  this 
type  declaration  and  the  three  definitions. 

3.1.3.  Associating  Labels  M'ith  Variables  and 
Transforms 

To  permit  the  association  of  security  labels  with  variables 
and  transforms,  it  was  necessary  to  extend  the  syntax  of  the  Ina 
Jo  language.  In  the  following  example,  SysLo  is  a  constant, 
p  is  a  formal  parameter,  and  each  ot  the  other  identifiers  is  a 
variable. 

CLEARANCE  Object  @  Ob ject_Leve 1 , 

Ob j«ct_Levcl  (3  SysLo, 

Buffer  (p)  @  Proc_Level  (p) 

This  declares  Object  to  have  (variable)  security  class 
Ob ject_l,evci,  Object_Level  to  have  (constant)  secu¬ 
rity  class  SysLo,  and  Buffer  (p)  to  have  (variable)  secu 
rity  class  Proc_Lcvol  tp)  (for  all  p  in  the  proper  domain). 
Each  of  the  expressions  on  the  right  side  of  the  '(«)’  must  be  a 
CJCt2rance_£xproi'Siori,defined  in  |4j. 

3.2.  Conjectures  Generated 

MLS  generates  a  single  flow  conjecture  for  each  transform 
in  a  level.  This  conjecture  is  of  the  fomt 

Criteria  i  Invariants  &  Effect 
— 

Secure (Flow} )  &  ...  &  Secui e (Flown) 

1  MLS  does  not  jncr.cntly  make  use  of  the  transitive  or  anu  symmetric  proper 
tics  of  dominates. 


If  Fiovr  is  the  flow  front  Source^  to  Target  ^  undei  con¬ 
dition  Cond.,thcn  Secure  (Flow.)  is  defined  as 

]  J 

Cond^  — >  New_of  (MLS_Label  (Target  ) 

dominates  MLS_Labcl  (Source^) 

The  MLS_Label  function  takes  a  (variable  or  transform 
parameter)  name  and  returns  a  Clearance_F.xpress ion. 
The  New_of  function  takes  a  Clearance  Expre ssion 
and  returns  the  same  Clearance _Expre ss ion,  with  all 
variable  references  replaced  with  N"  variable  references.  If 
any  Target  ^  or  Source^  does  not  have  an  associated  label, 
then  the  conjecture  generated  for  that  transform  will  be 
False,  and  all  the  flows  for  that  transform  will  be  listed,  as  in 
181. 

In  addition  to  the  flow  conjectures,  MLS  forces  the  user  to 
prove  the  assumptions  (1)  -  (5)  listed  in  section  3.1.2,  to  ensure 
that  the  information  built  into  MIS  follows  front  the 
specification. 

4.  The  MLS  Preprocessor 

The  Ina  Jo  language  allows  many  forms  of  nondetermin¬ 
ism.  We  pointed  out  earlier  (section  2.1)  that  whenever  a  state 
transition  is  nondeienninistio,  the  flow  tool  makes  the  conserva¬ 
tive  (i.e.,  secure)  assumption  that  an  implementation  may  refer¬ 
ence  (the.  image  of)  every  state  variable.  Therefore,  it  is  impor¬ 
tant  that  a  specification  intended  for  flow  analysis  be  as  deter¬ 
ministic  as  possible. 

We  have  developed  a  preprocessor,  henceforth  called 
PREMLS.  which  can  be  used  to  ensure  that  some  forms  of  non¬ 
determinism  do  not  appear  in  the  specification  seen  by  the  Ina 
Jo  processor.  PREMLS  is  invoked  via  a  command-line  Hag  to 
the  inajo  c>  mmand,  and  acts  as  a  filter:  it  reads  an  Ina  Jo 
specification  ind  produces  a  new,  presumably  more  determinis¬ 
tic,  specifica;  on.  In  the  remainder  of  this  section  we  discuss 
PREMLS,  and  present  guidelines  for  writing  deterministic 
specifications. 

PREMLS  makes  deterministic  specifications  easier  to  write 
(and  read)  by  providing  short  hand  notation  for  certain  expres¬ 
sion  forms  required  by  the  Ina  Jo  semantics  of  No-change.2  The 
user  writes  a  nondcicrministic  Ina  Jo  specification,  and 
PREMLS  tries  to  make  die  specification  deterministic  by  aug¬ 
menting  transform  effects  with  No  change  clauses,  which  assert 
that  some  variables  do  not  change  under  some  conditions. 
PREMLS  performs  two  kinds  of  No-change  augmentation  often 
regarded  by  Ina  Jo  users  as  tedious  to  do  manually  and  unneces¬ 
sarily  difficult  to  read.  This  augmentation  occurs  only  in 
transform  effects.  The  rest  of  a  specification  will  be  unchanged. 

Use  of  PREMLS  is  not  required;  PREMLS  is  merely  a  con¬ 
venience  for  specification  writers  unaccustomed  to  the  Ina  Jo 

2  |M  am!  ('ll  bulh  intlutlc  discussions  o(  Ina  Jo  No  change  senanhts,  arid  ex 
plain  why  ihe  Ina  Jo  convention  is  ptcfcrahle  for  formal  sjxxifii.  lion  to  the  "no 
pt Lined  occurrence’*  convention  of  SPfcC’lAL,  even  though  the  latter  is  more  con 
vement. 
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language.  Any  specification  that  could  be  presented  to  MLS  via 
PREMLS  could  also  be  presented  to  MLS  directly,  by  writing  a 
deterministic  specification  in  the  first  place. 

4.1.  Augmentation  of  Array  Updates 

Consider  the  effect 

(1)  N"A(x)  -  y 

This  is  a  nondeterministic  specification  of  the  new  value  of 
state  variable  A.  The  above  expression  means: 

(2)  A"i ; Tvpe-of-x  ( 

N"A(i )  -  (  i  «  x  ->  y  <>  N"A(i)  )) 

In  English  this  says  that,  in  the  new  state,  the  xrh  element  of 
variable  A  has  a  known  value  (namely,  the  old  value  of  y),  but 
every  other  element  of  A  has  an  unknown  value.  (N  "A  (  i  )  = 
N"A(i)  is  a  standard  lna  Jo  way  of  indicating  an  unknown 
value;  all  we  know  about  N"A  ( i )  is  that  it  is  equal  to  itself.) 

It  is  often  the  case  that  a  specification  writer  wishes  to 
indicate  that  a  finite  number  of  elements  of  a  parameterized 
variable  may  change,  with  all  other  elements  unchanged.  One 
way  of  doing  this  is: 

(3)  A"i : Type-of -x  ( 

NMA(i  )  -  (  i  -  x  =>  y  <>  A(i)  )  ) 

The  difference  between  (2)  and  (3)  is  that  (3)  specifies 
N"A  ( i )  =  A  ( i )  for  all  but  the  single  element  that  is  expli¬ 

citly  changed.  Therefore,  (3)  is  entirely  deterministic. 

PREMLS  expands  expressions  like  (1)  to  the  deterministic 
form  exemplified  by  (3).  However,  to  avoid  any  confusion 
about  which  semantics  are  expected  by  the  specification  writer, 
PREMLS  will  perform  this  expansion  only  if  the  expression  in 
(1)  is  enclosed  in  n rackets: 

(4)  (N"A(x)  -  y] 

A  specification  could  thus  include  both  kinds  of  no-changc 
semantics.  Expression  (.1)  will  not  be  expanded,  and  will  be 
interpreted  by  the  flow  tool  as  (2).  Expression  (4)  will  be 
expanded  to  the  deterministic  expression  (3). 

We  call  these  bracketed  expressions  array  updates.  Note 
that  the  brackets  are  not  part  of  the  lna  Jo  language,  so  a 
specification  that  contains  array  updates  must  go  through  the 
preprocessor  before  it  can  be  submitted  to  the  lna  Jo  processor. 
The  general  form  of  an  array  update  and  further  examples  are 
presented  in  [4], 

4.2.  Augmentation  of  Conditionals 


the  state  The  problem  here  is  again  that  the  semantics  of  no¬ 
change  do  not  agree  with  this  interpretation.  Making  the  lna  Jo 
meaning  of  this  example  explicit,  wc  have 
(10)  (  Except  ion_l  ->  N"Error  -  El 

4  N"State  —  N"SLat.e 

<>  Excopt_ion_2  =>  N”F.rror  -  E2 

4  N"State  =  N"5tate 

<>  ... 

<>  N"State  -  Someexpression 

4  N"Error  -  N"Error) 

from  which  one  can  see  that  every  case  leaves  some  part  of  the 
new  state  undefined.  This  may  be  the  intention  of  the 
specification  writer,  but  giving  such  a  specification  to  lna  Flo 
would  probably  be  a  waste  of  time,  because  MLS  would  assume 
that  information  flows  from  every  state  variable  to  State  in 
the  E>  ption  cases,  and  from  every  stale  variable  to  Error 
in  the  final  case. 


The  intent  of  (9)  is  more  commonly 

(11)  (  Exception_l  *■>  N"Error  -  El 

4  NC" (State) 

<>  Exception_2  =>  N"Error  =  E2 
4  NC" (State)  ■ 

<>  ... 

<>  N"State  -  Some_expression 
4  NC" (Error)  ) 


PREMLS  augments  conditionals  as  npx-essary  to  change  expres- 
sionc  like  (9)  ir.io  expressions  like  (11)  Ir;  ^erjcrtil  RR E\iIS 
ensures  that  each  branch  of  a  particular  conditional  modifies  the 
same  variables  as  every  other  branch  of  that  conditional.  This 
is  true  for  every  conditional  in  every  transform  effect  (but  no; 
for  conditionals  in  maps  or  constraints).  PREMLS  does  no; 
ensure  that  every  branch  modifies  the  same  elements  of  the 
same  variables;  th  t  is  an  unsolvable  problem,  so  PREMLS 
ignores  parameters  when  augmenting  conditional  expressions. 
For  example,  given  the  expression 
(12)  (  Bl  ->  N"W  (a)  =  32 

<>  B?  =>  N"X  (b)  -  33 
<>  N"V  =  0  ) 


PREMLS  would  produce 

(13)  (  Bl  =>  N”W (a )  -  32  5  NC"(X,V) 

<>  B2  =>  N"X(b)  -  33  4  NC" (W, V) 

<>  N"V  -OS  NC" (W, X)  ) 

which  is  still  nondeterministic.  If  the  specification  were  instead 

(11)  (  Bl  =  >  | N"W (a)  =  32) 

<>  B2  =>  |N"X(b)  =  33] 

<>  N"V  -  0  ) 


An  lna  Jo  transform  typically  represents  some  system 
function  that  either  performs  a  state  changing  action,  or 
“returns”  an  error  code.  For  e'  ample,  consider  (he  effect 
(9)  (  Except i on_l  ->  N"Error  -  El 

<>  Except ion_2  =>  N"Error  =  E2 
<>  ... 

<>  N"State  -  Some  expression  ) 

We  would  like  to  be  able  to  interpret  this  as  saying  that  if  any 
error  condition  occurs,  then  signal  the  error,  otherwise  update 


then  PREMLS  would  produce  the  deterministic  specification 
(3  3)  t  Bl  =>  A" i : Type_of _a  (  N"W(i)  = 

(  i  -  a  ->  32  <>  W(i)  )  ) 
4  NC"  (X,V) 

<>  B2  =  >  A" i  : Type_of  _L>  (  N"X(i)  - 

(  i  -  b  ->  33  <>  X(i)  )) 
4  NC" (W, v; 

<>  N" V  =04  NC" (W, X)  ) 
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5,  Summary 

The  Ina  Flo  flow  tool  is  currently  being  used  on  at  least 
one  internal  and  one  external  A 1  1 3 1  development  project.  We 
expect  the  internal  project  to  suggest  improvements  in  the  SRM 
tool;  one  external  project  has  alteady  suggested  numerous 
improvements  in  the  MLS  tool,  and  we  expect  to  continue 
refining  the  MLS  tool  to  make  it  more  useful  for  A1  covert 
channel  analysis. 

One  area  where  improvements  will  be  made  is  in  handling 
variable  security  labels.  We  believe  MLS  is  now  secure,  but  it 
is  too  conservative,  in  that  the  conjectures  it  generates  for  vari¬ 
able  labels  are  often  much  stronger  than  necessary  to  ensure 
security.  The  appendix  includes  an  example  of  this. 
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Appendix 

The  following  table  contains  a 'summary  of  the  less  obvi¬ 
ous  Ina  Jo  syntax  used  in  the  paper. 


the  notation... 

means... 

A" 

for  all 

N" 

new  value  of 

NC" (v) 

N"v  =  v 

—  > 

implies 

(b=>s<>t ) 

if  b  then  s  else  t 

The  following  example  demonstrates  input  to  and  output 
from  the  Ir.a  Jo  processor  when  the  MLS  option  is  selected.  The 
example  specification  (shown  in  figure  1)  is  written  for 
PREMLS  -  note  the  T  and  ’]’  brackets  in  some  of  the 
transforms.  Also  note  that  the  INHIBIT  flag  is  used  to 
suppress  the  correctness  and  consistency  conjectu.es  ordinarily 
paxJuccd  by  the  lna  Jo  processor. 

Figure  1  is  a  specification  of  a  simple  resource  manager 
that  uses  the  low  v  tier  mark  security  policy. 

Figure  1  -  Example  specification  Iwm.ina 


ST1TLE  Jo w  Water  Mark  example  for  Ina  Flo 
SPECIFICATION  Low  Wat  et  _Mai  k 
I.EVEL  Top_L(_-vel  MLS  Inhibit 

TYPE 

t. ,  /*  this  is  the  object  type  */ 

Process, 

MLS_Labe 1 

CONSTANT 

dominat  es  (MI,S_Label ,  MLS_I.abol):  Boolean, 
SysLo,  Syslli:  MI.S_I.abe J , 

Proc  Love  1 ( Pi ocess )  :  MLS  Label 
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VARIABLE 

Object  ,  Ruff 01  (Process)  :  t,' 

Cun:  P;  or.:  Process, 

Ob  ject_I.evel :  MLS_Labcl 

CLEARANCE 

Object  0  Objec  L_Level, 

But  for  (p)  0  Proc  Level  ;p)  , 

Crui.  Ptoc  &  Sysl.0, 

Ob  ject_  Level  @  SysLo 

AXIOM 

A‘'lev:  HLf.Labc-1  (  Dorai  states  (lev,  lev)  , 

4  A"lev:  MLS  Label  (  Dominates  (oysHi,  lev)  ) 
4  A"lov:  MI. Label  (  Dominates  ( lev,  Sys  bo)  ) 
4  A"il,  12  :MLS_Labei  (  Dominat  es  ( 1  1. 12) 

4  Dominates (12, 1 1) 

->  11  -  12  ) 

4  A"il,  12,  1 3 :M',S_Labe  1  (  Dominates  (11 ,  1?) 

4  Dominates ( 12, 13) 

->  Dominates  (1 1,  13)  ) 


INITIAL 

,V'p:  Process  (  Dominates (Ob ject_Level , 

l'ioc_Level (p)  )  ) 


CRITERION  True 

TRANSFORM  Read 
EFFECT 

(  Dot'd  nates  (Proc_Level  (OtttiPror) , 
Object  _Level ) 

->  (N"But  fer  (Cur  r_  Proc)  -  Object) 

<>  NC" (Buffer)  ) 


TRANSFORM  Write 
EFFECT 

(  Dorni  nat  es  (Ob  ject_Level, 

Ft  oc_Level (Cur  t_Pcoc) ) 
«>  N”Objoct_Levei  - 

Pt.oc_l.evel  (Cun_Proc! 
i  N"Object.  “  Buf  f  cr  (CurrJ’roc) 

<>  NC" (Object,  Ob jeet_Level)  ) 


TRANSFORM  Reset 
EFFECT 

i  Domi nates (Proc_Level (Curr_Proc), 
Object _Levcl ) 

■=>  N"Ob ject_Levcl  *•  Syshi 
<>  NC"  (Ob jcct_I.evel ;  ! 


CLEARANCE 

Read  0  Proc_I,evel  (Cur t  Pr  OC)  , 
Wjite  0  Froc_Level  (Curt  _Proc) 
Reset  0  Proe_Level (Cut r_Proe! 

EL  Top_Level 
END  Low  Water  Hark 


The  features  of  (lie  specification  in  Figure  1  lhat  vve  wish  to 
pn.nl  out  ,uc 

(I  The  flag  Ml, 3  appeal'  on  die  Level  line.  This  causes 
the  Ina  jo  processor  (•>  invoke  MIS  on  level 
TOf'_l  t'  vo  1 . 

(?)  There  an:  declarations  for  MLE  Labe  1,  Dominates, 
SysHi  and  .sysbo.  Each  of  litese  names  is  built  into 
MIS,  hut  not  into  the  ln:t  Jo  processor  itself,  so  they  must 
Ik*  declared  in  the  specification  if  they  art  to  is:  used. 

(?)  The  label  assigned  to  buffer  is  a  variable, 
Proc  Level.  The  implications  of  this  are  discussed 
after  figure  2. 

(4)  The  three  assumptions  built  inti  MIS'  ate  explicitly 
specified,  if  they  were  not,  the  corresponding  conjectures 
generated  by  MiS  would  (probably)  not  be  provable.  This 
is  a  consistency  check  between  MLS  and  the  specification. 

(5)  The  clearance  declarations  for  the  three  transforms  are 

superfluous,  because  none  of  the  transforms  has  parame¬ 
ters  In  general,  a  transform  requires  clearance 

specification  only  if  it  has  parameters,  because  it  is 
through  these  parameters  that  information  may  liow  from 
the  transform  invoker  to  modified  variables. 

The  next  figure  eomtnins  an  abridged  listing  prixuiced  by 
the  command  tnajo  -p  iwrtv*  i  he  listing  is  ton 'too  Died  except 
as  noted. 

Figure  2  -  Listing  of  Iwnt.ini* 


2 - SPECIFICATION  Low__Wat.fr  Marx 

3 - LEVEL  Top_Levol  MIS  Inhibit 
<i  ■ 


many  bnes  deleted 


$  6  *• 

5 7 -  TRANSFORM  W i i to 


50- 


59- r.f  feet 

60-  ( 

6  1  •* 

62- 

63- 

64- 
05- 


Dominat  lss  (Ob  jec5_LrVvel , 

Pi  oc_Leve.l  (Cur  r  Proc)  ) 

«•>  N"  Obji'i  t  Love  i 

Pr  or_I.t  v,*]  (Fur  r_Pi'or  ) 

L.  ,V  Ob  jf.'Ci.  «*  Buf  l er  (On  .*  ior  ) 


66-  <>  NC'  (Ob joi't Ob jeci\_]..ovo  1 ) 

67-  ) 


*  TV  * -ji'  fnif,  vovvc5  iV  ln%  Jo  procw.oi  10  invoke  tV  prepi  oce.vk»r  on 
lwm.ir.4t.  then  ULf  tiii:  i>uf(.'in  of  ip*?  pnrprtxcssor  *s  its  input. 
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1’ioc  Level (Curr  Pioc))) 


many  lines  deleted 


TtiEOP-EM  FOR  Syslli: 

A"  1  ov  :MLS_L,st  vl  tDomi  nates  (Kystti ,  lev)) 

THEOREM  FOK  SysLo : 

A"  lev  :MLS_1-J>bei  (Dc.mi  netes  (J  ev,  SysLo)) 

THEOREM  FOK  Don,;  nates  -  reflexive: 

A"  lev :  Ml  S_Lnbe  1  (Dominates  ( lev ,  lev)) 

THEOREM  FOR  Dominates  -  Antisymmetric: 

A."  lev!,  1  e  -■  2  : MLR_Labo  1  ( 

Domi net es ( levl,  lev2) 
s  Dominates  (lev?. ,  levl) 

■>  levl  »  lev2) 


THVORiOM  FOR  Dominates  -  Tionsitive: 

A"  levl,  lev2,  lev3  :MLS_l.abel  ( 
Dominates*  O  evl  lov2l 
s  Dominates  ( lev2,  levl) 

->  Dominates  (levl ,  levl)) 


Flow  conjecture  for  Transform  Read  deleted 


Flow  Conjecture  for  Transform  Write 
Ctl  True 

£  &  (  Dominates (Ob ject_Level 

,  ProC  Level (Cui i_Proc) ) 

«>  N"  Ob  ject__Leve) 

-  ProcLevel (CurrJProc) 
4  N"  Object 


FI 


l T2 


4 

5 


4 


-  Builer  (CurrJ’ior) 

<>  N"  Object  =  Object 
4  N"  i>b ject_l.ovcl 

Ob ject_Loval ) 

M”  Cur  l  Free  ■=  Curr  L'roc 
A"  #0:Pi:ocess( 

11  Buffer  (#0)  -  Buffer  (#0)) 

(  Dominates  (Ob  ject_Level 

,  Proc_Lovel  (Curr_Proc)  ) 

&  True 

->  Dominates  (N"  Object_l.evel 
,  Object  _  Level  )  ) 

(  Dominates (Ob jeet  Level 

,  Pioc  Uvel  |i,'uii  JToc)  I 
&  True 

->  Dominates (N"  Ob jeot_Level 


Flow  Conjecture  for  Transform  Reset 
True 

4  (  Dominates (Proc  Level (Curr_rroc) 

,  Ob ject_Level ) 

->  N"  Ob  iect__Level  -  Syslli 
<>  N"  Ob ject_Level  -  Ob joct_Level) 
&  N"  Curr_Proc  -  Curr_Proc 
4  A”  #0:Process( 

N"  Buffer (#0)  =  Buffer (#0)) 

&  N"  Object  “  Object 
->  (  Domi nates ( Proc_Leve 1 (Cur r_Proc ) 

,  Object_Level) 

4  True 

->  Dominates (W  Object_Level 
,  Ob ject_Level ] ) 

88-F.ND  Low  Water  Mark 


The  first  five  conjectures  (called  THEOREMS),  for  SysHi, 
SysLo  and  Dominates,  will  be  included  in  the  listing  and 
itp  file  whenever  MLS  is  invoked.  In  this  case  each  of  them  is 
proved  either  automatically  by  the  IT  P,  or  with  a  single  instan¬ 
tiation  command  by  the  user.  This  is  expected,  since  the  con¬ 
jectures  ate  stated  in  the  specification  as  axioms. 

The  conjecture  for  transform  Read  is  also  ptoved 
automatically,  and  is  not  shown  in  the  Figure.  The  conjecture 
for  transform  Reset  is  not  proved  automatically,  but  is  easy 
to  prove  with  die  ITP.  Transform  Write  is  troublesome, 
because  it  downgrades  Object  (by  changing 
Ob  joet_I.ovel).  Recall  the  general  font  of  a  flow  conjec¬ 
ture: 

Criteria  4  Invariants  4  Effect 
-> 

Secure (Flow,)  4  ...  4  Secure (Flow  ) 

i  n 

In  the  flow  conjecture  for  transform  Wi  ite  in  Figure  2,  the 
first  line,  marked  C'iX,  is  the  conjunction  of  the  criterion  and 
the  (implicitly  true)  invariant.  Beginning  on  the  second  line, 
and  marked  g,  is  the  augmented  effect  of  transform  Write. 
Beginning  on  the  line  marked  11  is  the  security  condition  for 
the  first  potential  flow,  and  beginning  on  the  line  marked  F2  is 
that  lor  the  second  potential  flow.4 

ML. S  ensures  that  no  downgrades  are  allowed  by  requiring 
proof  that  the  new  value  of  the  (variable)  label  of  the  potentially 
downgraded  variable  dominates  the  old  value  of  that  label. 
This  requirement  is  the  source  of  FI,  Unfortunately,  we  can 
not  prove 

dominates <N"Ob jectLevel ,  Ob ject_Level ) 

(unless  Ob  ject_Levol  -  Proc_Level  (Curr_rroc) ). 
We  can  argue  informally  that  the  transform  is  secure,  because 


*  Ttre  muting;  asiocitirU  with  the  flow  tor,  pin, c  for  irunsfomr  Write  wc-c 
not  gencivicd  by  the  flow  luol  \hey  were  fcided  fci  tfm  paper. 
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the  information  in  Object  in  the  old  state,  at  level 
Object^Level,  has  been  replaced  in  the  new  state  with 
information  at  level  Proc_Level  (Curr_Proc)  (in  the  old 
state),  which  is  N"Object_Level. 

This  example  points  out  that,  although  it  is  possible  to  use 
variables  as  labels,  MLS  is  overly  conservative  about  them,  in 
the  sense  that  sonic  secure  flows  will  not  be  provably  secure 
from  the  conjectures  generated  by  MLS.  We  are  working  on 
this  problem. 


182 
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Abstract 

Current  generation  tools  and  techniques  for  formal 
verification  have  inherent  limitations  that  prevent 
them  from  being  applied  on  a  larger  scale.  We  de¬ 
scribe  an  lR&cD  effort  underway  at  TRW  to  augment 
the  Gypsy  Verification  Environment  (GVE)  with  a 
knowledge-based  “verifier’s  assistant."  The  result¬ 
ing  methods  and  tools  will  support  the  construction 
of  deductive  theories  to  extend  the  practical  range 
of  today’s  formal  verification  tools.  A  prototype  De¬ 
ductive  Theory  Manager  (Dl'M)  is  being  developed 
to  maintain  appropriate  knowledge  bases  and  in¬ 
teract  8emi-automatically  with  the  GVE.  Candidate 
knowledge  bases  are  simultaneously  under  develop¬ 
ment. 

Introduction 

Formal  verification  is  the  primary  distinguishing  fea¬ 
ture  of  Division  A  requirements  in  the  TVusted  Com¬ 
puter  System  Evaluation  Criteria  [l]  Obviously, 
the  National  Computer  Security  Center  (NCSC)  at¬ 
taches  considerable  importance  to  formal  methods 
and  the  Al  level  of  assurance.  Al  currently  repre¬ 
sents  the  highest  degree  of  trust  recognised  by  NCSC 
for  multilevel  modes  of  operation. 

Substantial  progress  has  been  made  in  applying 
formal  methods  to  computer  security  over  the  last 
fifteen  years.  A  fair  amount  of  success  has  been 
achieved  in  developing  secure  operating  systems  and 
verifying  them  to  the  Al  level  To  developers  of 
large  scale,  mission-oriented  systems,  however,  in¬ 
formation  security  technology  in  general,  and  formal 
verification  technology  in  particular,  is  still  lacking 
in  important  areas.  For  systems  designed  to  meet 
the  C?/Bl  level  of  the  Criteria,  it  can  be  argued 
that  sufficient  technology  exists  for  designing  cost 
effective  systems.  Nevertheless,  it  is  clear  that  such 
an  argument  cannot  be  made  for  systems  designed 


to  operate  in  multilevel  mode,  that  is,  requiring  a 
Trusted  Computing  Base  (TCB)  certified  in  the  B2- 
A1  range. 

Formal  specification  and  verification,  whether  to 
meet  computer  security  or  any  other  requirements,  is 
one  of  the  most  challenging  problems  facing  defense 
system  developers.  Whereas  verification  of  operat¬ 
ing  system  kernels  has  received  widespread  atten¬ 
tion,  comparatively  little  work  has  gone  into  other 
aspects  of  trusted  system  verification.  Formal  verifi¬ 
cation  of  trusted  applications  software,  for  instance, 
is  largely  an  unexplored  area.  It  differs  considerably 
from  operating  system  verification  efforts  where  the 
goal  is  usually  to  prove  that  some  well  defined  se¬ 
curity  model  properties  hold.  In  contrast,  verifica¬ 
tion  of  applications  software  involves  proving  that 
derived  security  properties  hold.  These  properties 
tend  to  be  complex  statements  of  functional  behav¬ 
ior  and  involve  much  more  effort  to  synthesise  and 
prove  than,  for  example,  an  information  flow  prop¬ 
erty.  Current  generation  verification  methods  and 
tools  are  ill-equipped  to  cope  with  the  volume  and 
complexity  of  proofs  that  axe  likely  to  result  from  a 
large  mass  of  trusted  applications  software. 

The  Gypsy  Verification  Environment  (GVE)  [2) 
is  the  most  commonly  used  of  the  NCSC-endorsed 
formal  verification  tools  for  computer  or  network  se¬ 
curity.  A  prime  attraction  of  GVE  and  the  Gypsy 
language  are  their  applicability  to  a  broad  range  of 
tasks'. 

•  Formal  statement  of  security  models 

•  Represent  ation  of  formal  top-level  specifications 
for  TC3s 

•  Formal  description  of  system  designs  (i.e.,  a  pro¬ 
gram  design  language) 

•  Proof  of  the  preservation  of  a  secure  state  in 
security  models 
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•  Proof  that  an  FTLS  complies  with  security 
model  requirements 

•  Proof  that  the  high-level  language  implementa¬ 
tion  code  satisfies  an  FTLS 

We  consider  GVE  to  be  the  best  available  method¬ 
ology  of  its  kind.  Nevertheless,  in  spite  of  GVE’s 
strengths,  the  practice  of  formal  verification  remains 
a  very  demanding  engineering  discipline.  Limita¬ 
tions  of  even  the  best  available  tools  and  techniques 
render  their  application  to  real  system  designs  ar¬ 
duous.  Chief  among  the  cui  it  GVE  limitations  is 
that  proofs  require  too  mucii  user  interaction  and 
direction,  especially  for  proofs  of  concurrent  sys¬ 
tems.  As  a  result,  considerable  GVE  experience  and 
theorem  proving  knowledge  is  required  to  carry  out 
proofs  effectively.  Such  weaknesses  tend  to  become 
magnified  by  the  scale  factor;  as  problem  complexity 
grows,  using  the  GVE  prover  successfully  becomes 
much  more  difficult. 

TRW  is  addressing  these  problems  as  part  of 
our  Multilevel  Applications  Security  Technology 
(MAST)  IR&D  project.  A  major  portion  of  this 
project  is  devoted  to  the  problems  v.  .ori..**.  veiinca** 
tion  for  systems  of  nontrivial  size.  The  remainder  of 
the  paper  introduces  our  overall  approach  to  solving 
these  problems.  This  work  is  still  in  its  preliminary 
stages  and  we  anticipate  its  continuation  through 
1988. 

Objective 

Our  goal  is  to  advance  formal  verification  technol¬ 
ogy  to  better  support  large  scale  veiification  efforts. 
We  have  devised  a  technique  to  enable  verifiers  to 
build  deductive  theories  for  particular  domains  of 
interest.  The  objective  is  to  be  able  to  manage  effi¬ 
ciently  the  complexity  of  large  scale  proofs  through 
knowledge-based  augmentations  of  existing  verifica¬ 
tion  systems,  GVE  in  particular.  Our  ultimate  goal 
is  to  be  able  to  support  the  design  proof  (A1  level 
of  assurance)  required  for  100K  lines  of  trusted  ap¬ 
plications  software. 

More  specifically,  our  objective  is  to  develop  a  tool 
that  can  be  used  in  conjunction  with  GVE  to  push 
the  practical  limits  of  formal  verification  technology. 
The  tool  and  its  associated  knowledge  bases  will  sup¬ 
port  model  verification  required  at  the  B  levels  of 
assurance,  and  formal  demonstration  of  the  corre¬ 
spondence  of  the  formal  top-level  specification  to  the 
model  at  the  A1  level. 


Achieving  efficient  proofs  requires  structuring 
them  into  subproofs  and  handling  each  one  inde¬ 
pendently.  Lemmas  are  the  mechanism  to  achieve 
this  structuring;  their  use  is  an  application  of  the 
classical  divide-and-ccnquer  technique  for  problem 
solving.  Lemmas  are  already  supported  by  the  GVE 
in  a  rudimentary  fashion.  In  addition,  other  types 
of  user-directed  theorem  proving  operations  are  pro¬ 
vided  by  the  GVE  to  control  proof  complexity,  in¬ 
cluding  expansion  of  function  definitions,  equality 
substitutions,  and  instantiation  of  variables. 

While  use  of  these  basic  features  within  GVE  is 
simple  and  straight  forward,  it  is  overly  burden¬ 
some  for  a  user  to  keep  track  of  all  definitions  and 
lemmas,  and  to  know  when  to  make  use  of  them 
during  a  proof.  Having  additional  automated  sup¬ 
port  for  GVE  proofs  would  greatly  extend  the  range 
of  formal  verification  technology.  It  would  permit 
more  realistic  secure  system  formal  top  level  speci¬ 
fications  and  would  improve  the  practicality  of  code 
level  proofs. 

With  the  capability  described  herein,  applications 
verifiers  could  easily  build  up  bodies  of  deductive 
knowledge  specific  to  their  particular  domains  of  dis- 

mi'  ....  n  i  .f  1  i  i  .i.i 

vOu ioc.  x  ins  vvuuiu.  ut  ui  vduic  uuj  mg  uoui  uie  apeci- 

fication  and  verification  phases.  Domains  relevant  to 
TRW’s  A  1-level  specification  and  verification  work 
are  being  investigated  for  their  applicability  to  this 
approach. 

To  summarize  our  overall  objective  for  this  effort, 
we  list  the  following  major  goals  of  our  proposed 
tools  and  techniques: 

•  Extend  basic  formal  verification  technology 

•  Enable  verification  of  large  amounts  of  trusted 
software 

•  Promote  reusable  verification  concepts  and  re¬ 
sults 

•  Make  verification  technology  more  accessible  to 
less  sophisticated  users 

Accomplishing  these  goals  will  lead  to  a  significant 
advance  in  the  technology  for  developing  A1  sys¬ 
tems. 

Approach  Overview 

Our  approach  is  based  on  the  introduction  of  an 
automated  tool  that  can  be  thought  of  as  a  veri¬ 
fier's  assistant.  Its  purpose  is  to  augment  the  theo¬ 
rem  proving  capabilities  of  the  GVE  with  problem- 
oriented  proof  heuristics.  We  refer  to  this  tool  as  a 
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Figure  1:  The  verifier’s  assistant. 

Deductive  Theory  Manager  (DTM).  Figure  1  depicts 
the  high  level  architecture  of  the  composite  verifica¬ 
tion  environment  that  results. 

In  this  architecture,  the  DTM  plays  the  concep¬ 
tual  role  of  a  smart  user  that  draws  upon  a  copious 
body  of  theorem  proving  knowledge.  This  knowl¬ 
edge  and  associated  heuristics  are  used  to  supple¬ 
ment  the  user’s  own  knowledge  of  the  problem  and 
skills  at  proving  theorems.  It  is  important  to  em¬ 
phasize  that  the  DTM  does  not  replace  the  user; 
the  user  is  still  ultimately  responsible  for  directing 
and  understanding  the  proof  process.  What  we  ex¬ 
pect,  however,  is  that  the  combined  team  of  user, 
DTM,  and  GVE  will  be  much  more  effective  at  ver¬ 
ification  than  a  user  and  GVE  alone.  The  DTM  is 
designed  to  operate  at  an  intermediate  level  of  detail 
with  respect  to  verification  problem  solving.  Thus, 
the  GVE  continues  to  be  concerned  with  low  level 
details  as  the  “verification  engine,"  but  now  we  are 
able  to  raise  the  user  to  a  higher  level  of  abstraction, 
freeing  him  to  worry  about  more  global  issues  in  the 
overall  verification  problem. 

The  DTM  itself  relies  on  knowledge-based  tech¬ 
niques  for  its  implementation.  In  particular,  we 
are  basing  our  effort  on  the  Knowledge  Engineering 
Environment  (KEE)  tools  developed  by  IntelliCorp 
[3 j .  KEE  is  a  commercially  available  software  prod¬ 
uct  for  implementing  expert  systems  and  knowledge- 
bused  components.  We  will  use  KEE  to  realize  our 
DTM  concept  and  maintain  the  various  knowledge 
bases  needed  to  support  formal  verification  activi¬ 
ties. 

In  Figure  1,  we  show  three  separate  interfaces  be¬ 
tween  the  various  entities.  The  user-GVE  interface 
is  the  same  as  it  normally  is,  except  for  a  slight  ex¬ 
tension  of  the  user  commands  to  support  user-to- 
DTM  requests.  In  the  normal  “on-line"  use  of  our 


configuration,  the  user  carries  out  proofs  via  com¬ 
mands  to  the  GVE.  When  requested  to  get  help 
from  the  DTM,  the  GVE  will  interact  with  it  via  the 
GVE-DTM  interface.  The  user  only  communicates 
directly  with  the  DTM  in  an  “off-line”  mode  for  the 
purpose  of  building  and  maintaining  the  knowledge 
bases. 

To  illustrate  the  type  of  interaction  proposed  for 
the  user-DTM-GVE  team,  consider  the  following 
scenario  for  conducting  a  proof. 

•  Suppose  a  user  is  trying  to  prove  a  theorem  of 
the  form 

Hi  A  ...  A  Hn  =*•  C. 

•  Assume  a  knowledge  base  lias  bter.  built  (pre¬ 
viously  proven  lemmas  and  heuristics  for  GVE 
theorem  proving)  and  that  information  about 
the  theorem  lias  been  supplied  by  GVE  (cur¬ 
rent  goal,  types,  function  definitions,  lemmas, 
etc.). 

•  The  user  issues  a  command  to  the  GVE  to 
request  assistance  from  the  DTM  (through  a 
Deduce  command).  A  typical  DTM  response 
would  he  to  return  a  set  of  actions  resulting 
from  matching  a  particular  set  of  rule  condi¬ 
tions  in  the  knowledge  bases. 

•  The  GVE  performs  the  indicated  actions  by  ma¬ 
nipulating  the  II,  or  C  as  appropriate. 

The  actions  that  can  be  prescribed  by  the  DTM  in¬ 
clude  all  the  inference  rules  normally  available  to  an 
ordinary  user  through  prover  commands. 

The  work  to  be  completed  in  1987  is  as  follows: 

•  Development  of  the  theoretical  methods  re¬ 
quired  to  support  a  deductive  theory  manager. 

•  Implementation  of  an  interface  from  the  GVE 
to  the  DTM  package  using  KEE  to  allow  them 
to  execute  cooperatively  on  the  Symbolics  Lisp 
Machines. 

•  Development  of  several  preliminary  knowledge 
bases. 

•  Construction  of  a  prototype  of  the  DTM  soft¬ 
ware. 

•  Evaluation  of  the  effectiveness  of  the  DTM 
on  proofs  developed  on  other  TRW  projects. 
Specifically,  the  number  of  interactive  user  steps 
will  be  compared  with  and  without  the  DTM. 


Methodology 

The  following  sections  summarize  the  essential  con¬ 
cepts  of  our  composite  verification  methodology. 

Deductive  Theories 

Formal  verification  is  an  application  of  mathematical 
logic.  A  logician's  concept  of  theory  is  a  set  of  valid 
formulas,  that  is,  formulas  that  arc  either  axioms 
or  can  be  proved  from  the  axioms  and  previously 
proved  theorems.  In  the  jargon  of  01  dinary  mathe¬ 
matics,  a  theory  would  include  axioms,  definitions, 
and  theorems.  Our  concept  of  deductive  theory  in¬ 
cludes  the  conventional  logical  concept  of  theory,  in 
the  context  of  the  Gypsy  language,  but  also  extends 
it  by  including  heuristics  for  GVE  theorem  proving. 
Thus,  a  deductive  theory  contains  axioms,  theorems, 
and  meta-information  for  proving  new  theorems. 

The  importance  of  deductive  theories  is  that  by 
gradually  developing  a  theory  and  storing  it  in  a 
knowledge-base,  an  increasingly  more  powerful  set 
of  facts  is  available  for  constructing  new  proofs  in 
the  future.  The  effort  to  prove  complex  theorems 
is  greatly  reduced  in  ihe  piesencc  of  a  lieu  body  of 
previously  proven  theorems.  In  t  he  absence  of  such 
knowledge,  proofs  must  be  derived  from  fir3t  prin¬ 
ciples,  which  will  undoubtedly  require  much  more 
work  to  complete.  A  well  organized  theory,  on 
the  other  hand,  allows  for  reuse  of  previous  effort 
and  provides  the  obvious  economies.  Good  (4|  has 
claimed  that  the  development  of  reusable  theories  is 
a  vital  part  of  making  formal  verification  practical 
for  realistic  applications. 

Our  approach  recognizes  the  importance  of  build¬ 
ing,  maintaining,  and  using  deductive  theories  in  the 
verification  process.  We  arc  pursuing  a  knowledge- 
based  implementation  to  capture  deductive  theo¬ 
ries  and  organize  the  knowledge  in  maximally  use¬ 
ful  ways.  Emphasis  will  be  placed  on  organizations 
for  efficient  search  and  retrieval  of  relevant  informa¬ 
tion  at  suitable  points  in  a  proof.  We  see  the  use  of 
deductive  theories  as  one  of  the  few  practical,  near- 
term  ways  to  make  verification  technology  “scale  up" 
to  the  level  of  realistic  system  sizes. 

It  is  useful  to  think  of  deductive  theories  as  being 
organized  into  natural  hierarchies.  We  see  the  need 
to  support  four  distinct  layers  of  theories  and  their 
corresponding  knowledge  bases. 

1.  The  lowest  level  theory  contains  genera)  knowl¬ 
edge  relevant  to  virtually  all  GVE  proofs.  Typ¬ 
ically  this  would  involve  properties  of  the  pre¬ 


defined  Gypsy  types  and  operators  (those  prop¬ 
erties  not  already  provided  by  GVE  itself). 

2.  Domain  specific  theories  include  special  infor¬ 
mation  related  to  broad  classes  of  applica¬ 
tions  (e.g.,  operating  systems,  database  man¬ 
agement). 

3.  The  next  layer  is  project  specific.  It  contains 
information  related  to  the  particular  approach 
and  architecture  of  a  single  application. 

4.  A  fourth  theory  is  strictly  personal.  It  enables 
a  user  to  define  rules  that  are  helpful  to  him, 
but  may  not  be  useful  to  another  person’s  style 
of  specification  and  proof. 

Verification  Strategy 

The  introduction  of  deductive  theories  and  their  au¬ 
tomated  support  permits  new  ways  of  organizing 
effort  on  large  projects.  In  particular,  deductive 
theories  allow  for  a  very  effective  division  of  labor 
based  on  the  relative  verification  skills  of  project 
members.  We  can  draw  an  analogy  between  veri- 

r  i  .  r* _  .  \.  _i _ _  t*  ■  _ 

Ul.lViV.Ml  OUIVV»a|C  UV  V  1 1VJ  JJl  »  I il  L  .  iV  19  V.U9VVlll0i| 

to  divide  software  development  efforts  into  two  ma¬ 
jor  types:  systems  software  and  applications  soft¬ 
ware.  The  systems  programmers  build  a  base  for 
the  applications  programmers  to  utilize,  likewise, 
verification  effort  could  be  divided  into  two  types: 
the  development  of  common-use  deductive  theories 
by  one  group,  and  the  verification  of  applications  by 
another,  which  makes  use  of  the  theories  developed 
by  the  first  group. 

This  division  of  labor  allows  us  to  take  maximum 
advantage  of  those  with  the  better  verification  skills. 
In  general,  it  takes  more  skill  to  “design  and  imple¬ 
ment”  a  deductive  theory  than  it  does  to  make  use  of 
one  to  prove  properties  of  an  application.  Therefore, 
by  dedicating  the  more  experienced  verification  tal¬ 
ent  to  theory  development  efforts,  we  can  maximize 
the  utilization  of  scarce  human  resources 

Proof  Tactics 

The  GVE  theorem  prover  accommodates  several  dif¬ 
ferent  tactics  for  carrying  out  proofs  There  are  ap¬ 
proximately  10  major  inference  roles  that  can  be  in¬ 
voked  by  a  user;  the  DTM  will  likewise  be  able  to 
invoke  these  same  inference  rules  It  is  up  to  the  the¬ 
ory  developer  and  knowledge-base  designer  to  define 
the  KEE  rules  so  that  these  commands  will  be  in¬ 
voked  at  the  appropriate  times. 


Two  ot'  the  GVS  commands  and  associated  proof 
tactics  are  especially  important  and  worthy  of  men¬ 
tion.  Assume  we  are  trying  to  prove  a  theorem  of 
the  form 

H !  A  . . .  A  Hn  =*►  C. 

The  use  and  c'aim  inference  rules  together  with 
other  information  allow  the  prover’s  attention  to  be 
directed  to  very  specific  goals. 

Use 

This  command  takes  an  instance  of  a  Gypsy  lemma 
L  and  adds  it  to  the  current  goal  as  an  extra  hy¬ 
pothesis: 

L  A  Hi  A  ...  A  Hn  =>•  C 

The  DTM  would  use  a  lemma  drawn  from  one  of 
its  knowledge  bases.  The  lemma  would  be  a  pre¬ 
viously  proven  fact  that  had  been  duly  recorded  in 
the  GVE’s  database.  Typically,  the  prover  would 
be  directed  to  Proceed  after  this  point  to  continue 
with  the  GVE’s  own  proof  heuristics.  Alternatively, 
additional  DTM-supplied  commands  might  form  the 
proof  continuation. 

Claim 

This  command  introduces  a  new  boolean-valued  ex¬ 
pression  Q  as  a  formula  that  is  claimed  to  follow  from 
the  hypotheses.  Two  new  cases  must  be  proved  as  a 
result: 

Hi  A  ...  A  Hn  Q 
Hi  A  ...  A  Hn  A  Q  =►  C 

The  first  shows  chat  the  claim  Q  is  valid  and  the 
second  that  Q  can  be  used  to  prove  the  original  con¬ 
clusion.  A  useful  special  case  occurs  when  Q  has 
the  form  P  =>  C  and  P  follows  automatically  from 
the  hypotheses.  This  makes  the  proof  of  the  original 
conclusion  from  the  claim  trivial  and  leaves  the  real 
work  in  trying  to  establish  the  validity  of  the  claim. 
It  is  thus  a  convenient  way  for  the  DTM  to  derive 
lemmas  “on-the-fly”  when  a  suitable  one  docs  not 
already  exist.  Note  that  this  technique  constitutes  a 
form  of  backward  chaining ,  although  claim  could  be 
used  to  achieve  forward  chaining  as  well.  Similarly, 
the  use  command  could  be  used  to  achieve  either 
forward  or  backward  chaining. 

Specification  Style 

In  order  to  make  the  DTM  approach  more  tractable, 
we  should  refrain  from  allowing  just  any  syntacti¬ 
cally  and  semantically  correct  piece  of  Gypsy  specifi¬ 
cation  to  be  used.  Instead,  theory  developers  should 


function  secure_atate 

(s:  protection_state)  :  boolean  » 

begin 

exit  (assume  result  iff 

s impl e_se cur ity_pr opart y(s) 

4  star_property (s) 

6  disci'etionary_88curlty_property  (a)) ; 
end; 

Figure  2:  Sample  security  model  definition. 

adopt  and  prescribe  a  style  for  writing  specifications 
that  facilitates  subsequent  analysis  by  the  DTM  us¬ 
ing  their  theories.  The  specific  style  chosen  is  not 
nearly  as  important  as  the  fact  that  one  is  adopted. 
This  permits  the  DTM  to  make  simplifying  assump¬ 
tions  concerning  the  form  of  expressions,  bodies  of 
function  definitions,  etc.  Coordinating  the  specifica¬ 
tion  writing  conventions  with  the  proof  strategy  will 
yield  significantly  better  results  in  the  long  run. 

Examples  of  styles  we  are  adopting  are  illustrated 
in  Figures  2  and  3.  Tht„e  are  based  on  a  Gypsy 
rendition  of  the  Bell-LaPaduia  security  model  [5j. 
Key  features  of  the  get.read  specification  style  are 
its  state  parameter,  exception  condition  parameter, 
conditional  exit  assertion,  and  encapsulation  of  con¬ 
ditions  in  the  function  valid. geLread.  Figure  4  ab¬ 
stracts  the  general  form  of  this  specification  style. 
If  the  DTM  and  its  knowledge  bases  can  assume  a 
similar  structure  in  all  associated  operations,  they 
can  make  use  of  more  efficient  rules  tailored  to  the 
general  style. 

Verification  Condition  Schemas 

In  the  same  interest  of  tractability,  we  will  also  make 
the  DTM  cognizant  of  the  form?  that  verification 
conditions  (VCs)  will  take.  For  many  computer  se¬ 
curity  applications,  such  as  proving  that  operations 
are  security  preserving,  the  VCs  will  occur  in  a  small 
number  of  special  forms.  For  example,  the  case  of 
proving  that  an  operation  is  security  preserving  has 
the  following  general  form: 

secure  (Si)  A  effects  (Si,  S2)  =>  secure (S2) 

Figure  5  shows  this  form  in  an  actual  VC.  By  insist¬ 
ing  that  specifications  for  each  operation  be  written 
in  the  same  way,  the  VCs  for  all  the  operations  will 
have  the  same  form.  This  greatly  facilitates  the  work 
of  knowledge-base  designers. 
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procedure  get_read 

(s:  subject;  o;  object; 
var  ps :  protection_state , 
var  dec:  rule_declslon)  = 

begin 

exit  11  Talld_get_read(s ,  o,  ps'.'1 
then  dec  «  granted 
&  ps  «  ps 1  with 

(  .b  :«-  ps  1  .b  <  : 

accessCs,  o,  read)) 
else  dec  ■  denied  k  ps  =  ps  ‘ 
li; 

end; 


lunction  valld_get_read 

(e :  subject;  o:  object; 
ps  :  protection_state) :  boolean  ■* 

begin 

exit  (assume  result  ill 
CpriTllegedCs, 

dlaer*tionary_examption) 
or  ps.m[s,  o,  read]) 

It  donlnates  (ps  Is  [s]  .  sec  , 
ps .fa [o] . sec) 

£  (privlleged(s . 

securl  ty_star_exeinptlon) 
or  domlnatos(ps . 1c [s]  sec, 

ps  lo[o]  sec)))  ; 


end; 


Figure  3:  Sample  Gypsy  specification. 


procedure  P  (  .  .  .  ; 

var  s :  state ; 
var  e :  exception)  = 

begin 

exit  11  valld_P(  .  .  .  ) 
then  e  ■=  OK 

*  s  «  a ’  with  (...) 
else  e  -  error  it  e  “  s' 

11; 

end, 

lunction  valld_P  (  .  .  .  ; 

a :  state)  :  boolean  = 

begin 

exit  (assume  result  ill 

<booloan  expreaslon>  ); 

end; 


Figure  4:  General  specification  form. 


Verllicatlon  condition  RULE_MACIIINE_B#4 
HI  :  ROLE  (NS)  •=  R1 
H2 :  SECURE_STATE  (PS) 

H3 :  VALI D_GET_READ  (SUBJ  (NS), 

OBJ  (NS) . 

PS) 

->  PS  with  ( 

. B  :■=  PS.B 

0  faeq. :  ACCESS  (SUBJ  (NS), 
OBJ  (NS), 
READ)]) 

«  PS#1  ft  D*1  «=  GRANTED 
K4  :  not  VALID.GET.READ  (SUBJ  (NS)  . 

OBJ  (NS) , 

PS) 

->  D#1  DENIED  It  PS  =  PS#1 


Cl:  SECURE..STATE  (PS#l) 


Figure  5;  Sample  verification  condition  (VC). 

Generics 

Some  of  the  key  advantages  of  the  DTM  are  that 
it  will  enable  the  user  to  develop  more  generic  the¬ 
orems  or  rules  than  possible  within  GVE.  For  ex¬ 
ample,  in  GVE  a  lemma  about  some  property  of 
sequences  must  state  the  specific  type  of  element  in 
the  sequence.  If  the  theorem  is  to  hold  for  fifteen 
types  of  elements,  fifteen  lemmas  are  required.  In 
DTM,  a  single  rule  using  a  generic  type  will  pi. ivide 
an  expression  of  the  concept  in  terms  of  all  possible 
element  types.  When  used  in  a  specific  proof,  the 
DTM  can  instantiate  a  generic  Jemma  to  provide 
GVE  with  the  specific  lemma  name  for  the  appro¬ 
priate  element  type. 

Similar  generic  capabilities  are  being  investigated 
for  functions  as  well  as  types.  Such  capabilities 
would  enable  the  expression  of  lemmas  in  which 
functions  referenced  within  the  lemmas  are  parame¬ 
ters  that  get  instantiated  with  actual  function  names 
when  invoked.  This  would  allow  expressions  of, 
for  example,  transitivity  for  sets  of  functions  rather 
than  requiring  individual  rules  or  lemmas  for  each 
case.  There  are  significant  theoretical  issues,  how¬ 
ever,  to  be  resolved  before  this  concept  can  be  em¬ 
ployed.  This  is  an  area  undergoing  further  study. 


Relation  to  Automated  Theorem 
Proving 

Part  of  the  motivation  for  introducing  the  DTM  con¬ 
cept  is  to  provide  an  automated  lemma  search  capa- 
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bility.  There  are  other  mechanical  theorem  prov¬ 
ing  syst-nis  that  provide  such  features.  The  Boyer- 
Mcore  theorem  prover  [6],  for  example,  has  a  very 
useful  facility  for  storing  and  retrieving  previously 
proven  lemmas.  Lemmas  in  this  system  have  the 
form  of  conditional  rewrite  rules: 


Prototype  Implementation 

TRW  is  currently  engage  a  in  developing  a  prototype 
of  the  DTM  concept  to  assess  and  demonstrate  its 
feasibility.  Following  is  a  description  of  the  imple¬ 
mentation  features. 


Ci  A  ...  A  Cn  =>  L1IS  ~  RHS 

Automatic  application  of  the  rules  proceeds  by  first 
attempting  to  unify  the  left-hand-side  (LHS)  with  a 
term  in  the  formula.  After  successful  unification,  the 
conditions  (Cj,  are  established  in  backward 

chaining  fashion  to  determine  whether  the  rewrite 
should  take  place.  There  is  no  way  to  be  any  more 
selective  than  this  in  the  application  of  lemmas. 

The  AFFIRM  system  [7]  also  has  a  very  elegant 
method  of  automatically  applying  rewrite  rules  to 
a  formula.  In  AFFIRM,  however,  rewrite  rules  are 
unconditional.  Hence,  there  is  even  less  control  over 
the  application  of  rules.  This  has  significant  limi¬ 
tations  when  trying  to  solve  more  general  problems 
than  operations  on  abstract  data  types,  which  is  AF- 
FIRM’s  primary  domain. 

Both  of  these  examples  represent  systems  that  do 
an  admirable  job  of  supporting  reusable  deductive 
theories.  However,  a  good  deal  more  control  over 
the  application  of  lemmas  la  required  when  dealing 
with  deep  and  complex  proofs.  The  widespread  cov¬ 
erage  attempted  by  term  rewriting  systems  is  effec¬ 
tive  when  proofs  are  shallow,  but  they  tend  to  be¬ 
come  overwhelmed  when  attempting  proofs  requir¬ 
ing  deeper  penetration. 

In  this  area,  we  feel  the  DTM  approach  offers  an 
advantage  for  complex  proofs.  Using  DTM,  it  is  pos¬ 
sible  to  define  very  selective  conditions  on  lemma 
invocation  and  thereby  channel  proofs  using  highly 
directed  forms  of  heuristic  knowledge.  Rather  that 
attempting  broad  coverage  through  rewriting,  for 
which  GVE  would  be  inappropriate  anyway,  the 
DTM  concept  allows  proof  guidance  that  is  much 
more  context  sensitive.  This  will  lead  *o  fewer 
lemma  invocations,  at  the  expense  of  raoi  ,mpu- 
tation  to  determine  what  to  apply.  Neven  less,  we 
feel  this  is  the  correct  tradeoff  to  be  making  with  a 
system  of  the  sort  that  GVE  represents.  It  allows 
more  of  the  verification  analysts  skill  to  be.  encoded 
into  the  knowledge  bases  and  relies  less  on  brute 
force  coverage  principles. 


DTM  Design 

TRW’s  DTM  prototype  is  hosted  on  Symbolics  Lisp 
Machines.  The  DTM  acts  as  an  advisor  and  helper 
for  the  user  doing  proofs.  Figure  6  shows  the  re¬ 
lationship  of  the  user  to  both  the  GVE  and  the 
DTM.  We  expect  that  there  will  be  multiple  knowl¬ 
edge  bases  used  simultaneously.  In  fact,  the  proto¬ 
type  supports  the  simultaneous  use  of  four  knowl¬ 
edge  bases  in  keeping  with  the  previous  description 
of  four  layers  of  deductive  theories. 

TRW’s  DTM  design  enables  the  user  to  perform 
proofs  in  any  manner  he  desires  with  or  without  its 
help.  If  a  user  wishes  the  help  of  the  DTM,  he  makes 
his  request  through  the  following  added  GVE  prover 
commands: 

•  Advise.  The  user  is  provided  with  a  list  of 
recommended  steps  to  be  requested  of  GVE. 

•  Deduce.  The  DTM  determines  the  same  set  of 
recommended  steps  as  with  the  Advise  option 
and  proceeds  to  feed  the  requests  automatically 
to  the  GVE. 

In  the  Advise  option,  no  actual  steps  are  taken 
in  the  proof  of  the  verification  condition  or  lemma. 
In  the  Deduce  option,  however,  the  proof  steps  are 
performed  It  may  turn  out  that  the  user  does  not 
want  the  particular  steps  taken  by  the  DTM.  In  this 
case,  the  user  still  has  all  of  the  standard  GVE  re¬ 
covery  options  available,  including  the  capability  to 
back  up  (erase)  one  or  more  proof  steps. 

For  the  prototype  DTM,  TRW  is  combining  GVE 
with  one  of  the  commercially  available  expert  sys¬ 
tem  tools:  KEE  by  IntelliCorp.  KEE  will  enable 
us  to  establish  a  prototype  within  a  short  period  of 
time  without  spending  time  building  infetence  en¬ 
gines  and  knowledge  maintenance  capabilities.  Fur¬ 
thermore,  KEE  offers  sophisticated  front-end  graph¬ 
ics  to  provide  a  very  efficient  user  interface  to  the 
DTM  knowledge  bases. 

For  this  application,  the  GVE  has  to  be  extended 
only  to  request  the  DTM  to  provide  advice  or  de¬ 
duction.  The  information  provided  by  GVE  to  the 
DTM  is  only  theorem  status  information  (e.g.,  cur¬ 
rent  theorem,  data  types,  function  definitions,  and 
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Figure  6:  Deductive  Theory  Manager  Architecture. 


lemmas).  The  DTM  only  reads  this  information;  it 
does  not  directly  modify  it  or  add  to  it.  A  set  of 
Lisn  interface  functions  has  been  introduced  to  re¬ 
trieve  information  from  G  v'E’s  internal  database  loi 
use  by  the  KEE  rules. 


Similarity  Function 


One  of  the  central  features  required  to  make  the 
DTM  work  is  the  ability  to  determine  the  similar¬ 
ity  between  expressions.  A  sir.iilarity  function  has 
been  defined  which  computes  the  similarity  between 
two  predicates.  It  can  be  used,  for  example,  to  com¬ 
pare  a  hypothesis  to  the  conclusion  or  to  compare 
the  consequent  of  an  implication  type  ot  hypothesis 
with  the  conclusion. 

The  function  works  on  expressions  represented  in 
Gypsy  internal  format;  all  symbolic  operations  are 
represented  in  prefix  format.  The  function  returns 
the  number  of  similarities  and  the  number  of  dif¬ 
ferences.  All  differences  are  returned  in  the  form 
of  pairs  indicating  the  symbolic  differences.  By  re¬ 
turning  the  actual  differences,  the  differences  can  be 
further  reduced  by  utilizing  additional  information 
contained  in  other  hypotheses  or  by  use  of  instanti¬ 
ations  if  Gypsy  Skolem  variables  are  present. 


Knowledge  Base  Design 

A  KEE  knowledge  base  contains  a  set  of  rules  that 


constitute  rules-of-thumb  or 


for 


aiding 


the  GVE  theorem  proving  process.  The  actions  of  a 
rule  form  a  set  of  GVE  user  level  commands  to  be 
performed.  A  few  of  the  simpler  rules  we  envision  for 
the  DTM  are  shown  in  Figure  7  using  the  syntax  of 
KEE.  The  actions  are  either  displayed  for  the  user  as 
advice  or  sent  automatically  to  the  GVE,  depending 
on  the  user’3  command  choice. 

The  first  rule  in  the  figure  states  that  if  there  is 
an  equality  in  one  of  the  hypotheses,  it  will  be  used 
to  make  a  substitution.  For  example,  consider  the 
following  theorem: 


P(x,  /(</))  A  y  =  z  =>  P(x,f(z )) 

By  making  the  substitution  of  z  for  y,  it  is  clear  that 
the  first  hypothesis  will  unify  with  the  conclusion  to 
complete  the  proof.  A  more  selective  version  of  this 
rule  having  additional  conditions  for  triggering  the 
substitutions  would  be  more  desirable  in  practice. 

The  second  rule  states  that  if  the  conclusion  of  the 
theorem  refers  to  a  function  that  is  not  mentioned  in 
any  of  the  hypotheses,  the  definition  of  the  function 
is  necessary  to  continue  the  proof.  In  GVE  terms 
this  generally  means  the  function  must  be  expanded. 
The  case  of  nonexpandable  Gyps)  functions  will  also 
be  considered. 

The  third  rule  provides  a  simple  mechanism  for 
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(IF  (the  hypothesis  of  DTM  is  ?Hyp) 

(Lisp  (Equality  ?Eyp)) 

(?H-Num  “  (Get-Num  ?Hyp)) 

THEN  DO 

(GVE  EqSub  TH-Num)) 

(IF  (the  conclusion  of  DTM  is  ?Cncl) 

(THyps  “  (Get-Hyps)) 

(?Func  “  (Find-Func  ?Cncl)) 

(Lisp  (Not-In  ?Func  ?Hyps)) 

(Lisp  (Find-Func  TFunc)) 

THEN  DO 

(GVE  Expand  ?Func)) 

(IF  (THyps  *=  (Get-Hyps)) 

(the  conclusion  of  DTM  is  ?Cncl) 

(the  lemma  of  DTM  is  ?Lemma) 

(?LCncl  “  (Get-Cncl  TLonuna)^ 

(?LHyps  “  (Get-Hyps  TLemma)) 

(?Diff  -  (Similar  ?Cncl  ?LCncl)) 

(Lisp  (Make-Equal  ?Cncl  ?LCncl)) 

THEN  DO 

(GVE  lae  TLemma)) 

(IF  (the  conclusion  of  DTM  ie  ?Cncl) 

(Lisp  (Buf-Sequence  ?Cncl)) 

(THyps  (Cet-Hypo)) 

(TOBuf  -  (GOB of  TCncl) ) 

(TIBuf  -  (GIBuf  TCncl)) 

(TTOBuf  -  (GBuf  TIBuf  ?Hyps)) 

(TTIBuf  -  (GBuf  TOBuf  THyps)) 

THEN  DO 
(GVE  Claim 

TTOBuf  sub  TIBuf  and 
TOBuf  sub  TTIBuf 
->  TOBuf  sub  TIBuf)) 

Figure  7:  Example  theorem  proving  rules. 

applying  lemmas  that  have  been  defined  in  the 
Gypsy  application.  Even  though  the  lemmas  are 
within  the  Gypsy  database,  the  GVE  theorem  prover 
is  not  aware  of  their  existence  until  the  theorem 
prover  user  identifies  the  applicability  of  a  lemma. 
The  user  introduces  a  lemma  into  the  current  proof 
by  the  command  use  lemma-name.  DTM  rules  can 
help  automate  the  process  of  identifying  applicable 
lemmas  as  is  shown  by  the  third  example  rule.  The 
use  of  the  SIMILAR  function  during  a  search  will  lo¬ 
cate  a  lemma  with  a  conclusion  similar  to  the  current 
goal.  Once  found,  the  MAKE-EQUAL  function  at¬ 


tempts  to  make  the  two  expressions  equal  by  making 
appropriate  instantiations  of  any  Skolem  variables. 

The  fourth  rule  is  much  more  complex.  It  ad¬ 
dresses  a  common  type  of  problem  encountered  in 
proving  properties  of  concurrent  systems.  If,  for  ex¬ 
ample,  one  wishes  to  show  that  security  is  main¬ 
tained  as  a  message  flows  through  a  system  con¬ 
sisting  of  multiple  processes,  it  must  be  shown  that 
security  is  maintained  as  it  flows  through  each  of 
the  individual  processes.  This  fourth  rule  accom¬ 
modates  such  a  proof  by  setting  up  the  steps  for  a 
transitivity  argument. 

The  DTM  rules  will  be  designed  to  complement 
GVE’s  capabilities.  GVE  already  has  some  built-in 
heuristics,  the  effects  of  which  can  be  seen  when  the 
user  issues  the  Proceed  or  QED  prover  commands. 
The  DTM  will  synthesize  higher  level  proof  heuris¬ 
tics  by  combining  sequences  of  ordinary  GVE  prover 
commands. 

Tool  Endorsement  Issues 

One  of  the  key  features  of  the  TRW  approach  is  the 
use  of  a  technique  that  will  provide  the  functional¬ 
ity  of  proof  heuristics  while,  at  the  same  time,  not 
affect  the  soundness  of  proofs.  The  DTM  is  only 
useful  if  the  final  proofs  are  performed  with  tools 
endorsed  by  the  NCSC.  Recall  that  the  DTM  inter¬ 
face  to  GVE  is  logically  equivalent  to  that  of  a  smart 
user.  Con..eqnent!y,  the  only  information  fed  to  the 
GVE  are  standard  GVE  theorem  proving  commands 
that  the  real  user  could  have  typed  if  he  were  able 
to  think  of  them.  There  i3  no  direct  modification  of 
the  proof  tree,  or  any  other  internal  GVE  data  struc¬ 
tures,  by  the  DTM.  Therefore,  the  GVE  remains  to¬ 
tally  responsible  for  ensuring  soundness,  just  as  it 
does  when  an  ordinary  user  is  entering  commands. 

Due  to  this  partitioning  of  GVE  and  DTM  en¬ 
vironments,  we  claim  that  the  DTM  should  not  be 
subject  to  NCSC  endorsement.  The  NCSC  or  any 
other  certification  authority  could  validate  proofs 
performed  under  a  GVE-DTM  configuration  quite 
easily.  All  that  is  required  is  to  capture  the  DTM- 
generated  prover  commands  and  merge  them  with 
the  user-generated  commands.  Then  a  replay  of  the 
proofs  on  a  conventional  GVE  system  that  has  not 
been  outfitted  with  a  DTM  should  suffice  to  estab¬ 
lish  the  validity  of  the  proofs.  Our  DTM  design  will 
contain  the  features  necessary  to  support  such  a  val¬ 
idation  activity. 

A  further  advantage  of  our  DTM  approach  with 
respect  to  GVE  integrity  is  that  its  knowledge  base 
is  extensible  by  the  user.  Thus,  automating  new 
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proof  heuristics  does  not  require  modifications  to  the 
GVE  itself,  with  ai!  the  attendant  ramifications  on 
NCSC  tool  endorsement.  One  need  only  add  the 
appropriate  rules  to  the  DTM  knowledge  bases. 

Development  Status 

The  GVE  and  KEE  systems  have  been  integrated 
under  the  Symbolics  6.1  operating  system  version. 
The  GVE  uses  Zetalisp  and  the  Lisp  functions  called 
directly  by  the  DTM  rules  are  in  Common  Lisp  (sup¬ 
ported  by  KEE).  The  design  places  GVE  in  control 
with  the  DTM  as  a  supporting  function.  The  user 
invokes  DTM  to  provide  advice  or  automatic  proof 
support.  The  only  required  change  to  GVE  was  to 
extend  re  GVE  theorem  prover  grammar  to  sup¬ 
port  the  two  new  commands.  The  DTM  function 
calls  provide  a  copy  of  the  current  goal  by  copying 
the  expression  from  a  local  GVE  variable  to  a  global 
vaiiable  accessible  by  KEE.  Several  functions  had 
to  be  written  to  extract  the  type  definitions,  func¬ 
tion  definitions,  and  lemmas  contained  in  the  GVE 
database. 

The  major  effort  in  the  DTM  implementation  is 
found  in  the  development  of  a  set  of  primitive  func¬ 
tions  that  facilitate  manipu  lation  of  the  GVE  syiii- 
bolic  expressions.  KEE  if  best  suited  for  reasoning 
about  objects  which  either  have  no  internal  struc¬ 
ture  or  are  reaoily  represented  as  structures  of  fixed 
composition  (e.g.,  an  object,  has  weight,  size,  color). 
While  KEE  poses  some  difficulties  in  the  manipula¬ 
tion  of  symbolic  expressions,  it  offers  some  advan¬ 
tages  in  terms  of  tracing  the  reasoning  process.  It 
has  a  full  set  of  tools  that  allow  the  tracing  of  both 
the  forward  and  backward  chaining  process. 

Most  of  the  early  work  has  been  in  the  develop¬ 
ment  of  rules  that  can  be  applied  whenever  the  nec¬ 
essary  preconditions  of  the  rules  are  satisfied.  The 
focus  of  the  future  work  is  on  extending  DTM  to 
be  more  of  a  planning  process.  Our  objective  is 
to  have  DTM  determine  a  series  of  GVE  theorem 
prover  steps  that  will  complete  the  proof  for  a  theo¬ 
rem.  The  DTM  will  proceed  forward  as  long  as  it  can 
make  progress.  It  will  backup  whenever  progress  is 
not  possible  and  consider  alternative  strategies.  One 
of  the  difficulties  is  that  the  DTM  must  be  able  to 
compute  the  effect  of  the  application  -A  each  of  the 
Gypsy  theorem  prover  commands.  For  commands 
like  BACKCHAIN,  it  i3  fairly  simple.  For  commands 
like  SIMPLIFY,  it  is  much  more  difficult,.  One  of  the 
possibilities  being  explored  is  to  use  the  GVE  Sim¬ 
plifier. 


Conclusion 

TRW  has  developed  a  novel  concept  to  enhance  for¬ 
mal  verification  technology.  We  expect  that  the  full 
elaboration  of  the  DTM  approach  will  lead  to  a  sub¬ 
stantial  advance  in  verification  capability.  The  pri¬ 
mary  benefit  of  this  work  is  an  increase  in  the  effec¬ 
tive  range  of  applicability  of  Gypsy-ba.,cd  verifica¬ 
tion  efforts.  This  should  make  feasible  Al  develop¬ 
ment  efforts  that  cuuently  are  considered  impracti¬ 
cal  due  to  the  potentially  large  amount  of  trusted 
software  required. 

Our  plans  are  to  continue  developing  and  evalu¬ 
ating  our  DTM  prototype  during  1987.  An  official 
GVE-to-DTM  interface  is  planned  by  employing  the 
services  of  Computational  Logic,  Inc.  In  1988,  we 
expect  to  refine  our  DTM  design  based  on  what 
is  learned  in  1987.  In  addition,  we  will  focus  on 
the  serious  development  of  knowledge  bases  for  var¬ 
ious  problem  domains  and  assess  the  gains  realized 
through  the  addition  of  a  DTM  capability. 
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AltSThACT 

Ah  approach  for  d**\  Hoping  formal  M-cmiiy  models  is  pre.vntrd.  Ii  is 
accompanied  by  :i  technique  tor  cxpies>IPg  an**  proving  models  in  UypM.  'I'lie 
appioaell  is  adapted  and  gciurali/.rd  from  the  Hell  md  ] ,.*\] *;«■*  11  ] ;*  model,  as 
presented  in  Secure  i'oinputrr  System:  l 'n i/ir ■/  Hxpptitton  and  A/» (tir*  Interpre¬ 
tation. 


1.  INTRODUCTION 

The  Trust t  d  i'ojnjmtcr  Systc.n  ICvahuitton  ('ritma  jCTitcnaj 
r*‘t)i»u«'s  class  B2  or  higher  systems  to  have  “A  formal  model  ol 
the  security  policy  supported  by  the  TUB...”  There  ha*  been 
uncertainty  concerning  how  efforts  to  meet  tin*  requirement 
could  be  meaningfully  and  productively  incorporated  into  a  sys¬ 
tem  development  effort,  and  little  has  been  said  about  tlu*  practi¬ 
cal  application  of  existing  modeling  concepts  Furthermore, 
minimal  guidance  exists  for  integrating  existing  formal  specifica¬ 
tion  and  verification  technology  with  the  task  of  developing  these 
forma  I  models.  It  is  our  hope  that  this  paper  will  shed  some  bgi  t 
oil  these  issues. 

For  those  who  would  rather  apply  txisting  formal  verifica¬ 
tion  technology  than  develop  it,  a  technique  for  expressing  and 
proving  models  in  Gypsy  and  an  approach  for  developing  a  gen¬ 
eral  class  of  formal  models  is  present  *d.  The  approach  is  iii  rived 
and  adapted  from  JHcl)7(ij  and  in/olve*  expressing  a  system's 
functionality  and  desired  security  properties  in  a  state  machine 
format  By  adapting  the  existing  Bell  and  LaFadnln  format,  we 
inheiit  the  concept  of  a  secure  system  being  a  sequence  of  secure 
stales  (with  important  caveats  to  be  mentioned  later),  the  base- 
security  theorem,  and  the  concept  of  rules  of  operation  (but  not 
the  particular  rules  d( scribed  m  [Bell7fij). 

Bell  and  Lnl’adula  has  been  subjected  to  the  “social  pro¬ 
cess*'  within  the  formal  verification  community  lor  many  years. 
Although  this  scrutiny  has  identified  shortcomings  (e.g  -  see 
]Mel,eaiiS7]),  much  of  the  basic  framework  of  the  model  is  still 
attractive.  By  adapting  Bell  and  Lal’adula,  our  approach  has  the 
important  advantage  of  being  expressed  m  terms  already  iamiliar 
to  our  audience. 

Experience  has  also  shown  that  Hell  and  LaUudu'a  is  not 
appropriate  for  ail  formal  security  modeling  efforts  Likewise,  we 
are  not  elaiming  that  out  adaptation  is  universal  or  is  the  final 
word  in  formal  modeling  However,  we  have  attempted  to  gen¬ 
eralize  our  approach  rso  that  a  larger  class  of  systems  can  be 
modeled. 

Section  •>  of  this  paper  describe*  the  goals  for  our  approach. 
Section  3  presents  a  high  level  view  of  the  modeling  techniques. 
Finally,  Section  1  gives  a  detailed  example  of  a  Gypsy  model  in 
the  context  of  a  message  filter  application.  The  discussions 
assume  that  the  reader  has  a  general  familiarity  with  the  Hell  and 
Lnl’atlula  model  ;is  described  in  [Hcll7fij  and,  to  a  lesser  extent, 


with  the  Gypsy  language  [GoodS-ij. 

2.  MODEL  FEATURES 

To  fully  appreciate  this  approach,  it  is  necessary  to  under¬ 
stand  what  we  hope  to  accomplish  by  developing  a  model  and 
what  benefits  we  think  tin-  process  can  provide  The  model 
should  not  be  thought  cf  as  a  more  abstract  FTLS  (Formal  'Fop 
Level  Spccifieat ion)  The  model  is  more  than  that  and  \ve  feel 
there  is  an  advantage  in  treating  the  development  of  the  model 
separately  from  the  development  of  the  FTLS.  Formal  modeling 
can  be  an  Hlecnve  method  for  developing  the  formalisms  that  will 
be  used  to  prove  the  FTLS. 

The  clear  and  accurate  presentation  of  system  properties  is 
a  model’s  most  important  objective.  Unfort  unatelv,  no  approach 
can  directly  aid  the  model  developer  in  this  process.  However, 
our  approach  has  many  of  the  details  worked  out  for  the  basic 
framework  and  allows  a  group  to  xmeent rate  on  the  issues 
related  to  their  specific  problem 

The  modeling  process  should  accomplish  more  than  *ais 
b.isic  requirement.  A  point  often  overlooked  is  that  the  process  of 
developing  and  writing  a  model  should  provide  insight  into  how 
security  requii  eluents  integrate  with  system  functionality 
Understanding  this  relationship  is  imperative  'This  is  esj-i  rial ly 
useful  (if  not  critical)  when  the  requirements  and  functionality 
have  been  defined  by  a  group  separate  from  the  system  develop¬ 
ers 

lu  I  lie  “best  of  all  possible  worlds”,  models  are  written  in 
the  initial  st-agt  s  of  a  system’s  development,  when  design  or  archi¬ 
tecture  decisions  arc  not  vet  made  or  are  vrey,  very  tentative.  To 
avoid  changing  and  rcpiovmg  the  model  to  accommodate  fluid 
designs,  the  model  should  be  isolated  from  the  architecture  and 
speed  ics  of  the  implement  at  ion  This  practice  can  represent  a 
substantial  reduction  in  modeling  effort.  A  second  reason  for  iso¬ 
lating  the  model  is  to  avoi*1  placing  unnecessary  constraints  on 
the  eventual  implementation.  The  notion  of  “unnecessary  con¬ 
straints”  is  somewhat  nebulous,  but  in  general,  the  model  should 
deal  with  requirements,  not  design.  A  state  machine  approach 
satisfies  this  nerd  (pule  naturally 
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3.  A  TECHNIQUE  AND  APPROACH  Poll  MODELING 

1  hi-1'  scot  loll  presents  a  high  Irvrl  description  of  an  approach 
fot  developing  ft *r in :t I  models.  llecaii.se  of  t l.t*  appioaeh’s  general 
ity  ami  the  variety  of  .situations  for  which  it  is  applicable  it  is 
not  possible  to  present  a  detailed  series  of  stops  to  tell  the 
developer  Imw  to  build  a  formal  model  An  example  is  mole 
appropriate,  since  it  can  give  further  insight  into  our  approach 
Seel  ion  1  presents  an  explanation  of  bow  this  technique  is  applied 
to  develop  a  model  lor  a  simple  message  filter. 

An  explic  it  goal  ol  the  approach  is  to  maintain  a  strong 
eoi  i e|at  :•  »ii  wit  h  the  Hell  and  laPadula  model,  as  cxpicsscd  in 
( He II 7li].  Wc  feel  that  our  :di*?s  and  techniques  are  faithful 
enough  to  t lies'1  concepts  to  develop  a  model  exactly  as  it 
appears  in  |Hell7t>]  and  adaptable  enough  to  apply  the  concepts  of 
the  model  to  a  wider  range1  of  situations,  such  as  having  different 
security  properties,  modeling  systems  other  than  general  purpose 
operating  systems,  or  rapturing  more  complete  notions  cf  secu¬ 
rity. 

The  approach,  in  the  spirit  of  |Hell7(>],  consists  of  thr< 

Si  eps; 

[I]  Defining  a  "framework'1;  a  framework  is  analogous.  to  the 
descriptive  capability  and  general  mechanisms  referred  to  in 
[He  1 170  j. 

\'2\  Defining  system  functionality  which  is  analogous  to  the 
.specific  solution:  facet . 

|3j  Proving  system  security,  which  is  the  process  of  proving  that 
1  he  functionality  specified  in  |2j  obeys  the  constraints 
defined  in  jii. 

3.1.  Defining  ft  Framework 

Hy  “framework,"  we  mean  the  foundation  upon  which  the 
model  is  based  A  framework  provides  an  arena  for  describing  a 
system  of  n  particular  class  but  does  not  delve  into  the  intended 
functionality  of  the  system  being  modeled.  For  example,  in 
|Hell7(ij,  tlie  framework  represents  a  security  kernel  for  a  general 
purpose  operating  system.  The  specific  system  that  this  is 
applied  to  is  Mult ies. 

Two  issues  addressed  in  the  framework  are  the  mechanics  of 
the  model  itself  and  tailoring  the  approach  to  a  certain  class  of 
system*,.  Hell  ami  baPadula  referred  to  these  two  issues  as  their 
models  descriptive  capability  and  general  mechanisms,  by  which 
they  attempt  to  capture  the  basic  elements  of  a  computer  system 
and  the  llimtat ions  to  be  placed  on  such  a  system’s  eltects  to 
maintain  the  defined  notion  of  security  “Mechanics  of  the 
model’’  refers  to  (lie  state  machine  architecture  and  the  style  in 
which  a  system  is  defined  to  b<-  secun  (not  the  actual  security 
properties).  Tailoring  the  system  deals  with  the  selection  of  secu¬ 
rity  pioperl ies  for  a  particular  ehiss  of  system  application  and 
identifying  the  class  of  system  to  be  modeled. 

3.1.1.  Mechanics  of  the  Model 

The  mechanics  of  the  model  describe  how  the  state  machine 
view  operates  and  the  mechanisms  used  to  reason  about  the  state 
machine-  If  a  state  machine  model  js  desired,  our  approach  takes 
care  of  several  fundament al  issues.  The  approach  addresses 
issues  such  as  how  to  represent  the  state  machine,  lunv  to 
represent  the  security  requirements,  how  U*  relate  them  to  the 
state  machine,  and  how  to  express  the  state  transitions  We  are 


not  claiming  that  using  the  approach  allows  these  issues  to  be 
Ignored  completely  *1  hry  must  be  addressed,  but  "lily  in  trims 
ol  ho\v  they  need  tv’  he  adapted  h»j  aspiiilu  application  -  a  much 
caste i  topic  to  deal  with  than  starling  fiom  scialch 

Wc  p res*- nl  details  of  how  the  mechanics  arc  established  in 
section  t,  but  in  short,  the  notions  of  subject ,  object,  and  security 
level  track  rat  her  straight  forwardly  from  |HrH7lij  An  '■action"  i*. 
a  -Maple  of  (UJV’ncw  state,"  “old  state")  and  the  term  "vv.seT’ 
is  the  action  set,  W,  from  Hell  amt  j .aFadul.i.  The  representation 
in  (iypsy  of. security  level  and  its  associated  concepts  of  el.issifua- 
t ion ,  category,  eic  is  also  vety  similar 

3.1.2.  Tailoring  the  Framework 

’Flic  largest  differences  m  defining  the  framework  between 
this  approach  and  [Hcll7(>,  arc  the  notions  of  Mat'  and  seem  it  y 
properties  A  cl.es  of  system  is  defined  by  the  state  components, 
as  th.'se  are  the  only  things  upon  which  rules  can  act  In  [Hell7t>\ 
a  state  is  a.  1-tuple  of  (b,ll,M,f).  representing  the  current  access 
set,  the  hierarchy,  the  access  permission  matrix,  and  the  security 
function,  respectively  This  notion  of  state  allows  rules  to  deal 
with  the  I  unci  lonalit  >  of  a  security  kernel  Howrvei ,  this  is  too 
limited  loi  many  security  applications  To  expand  or  redefine  the 
potential  fund  louality  of  the  system,  it  is  necessary  to  change  the 
state  components  of  j  Hoi  17  ti  j  Our  approach  supports  this  by  m*t 
having  any  prescribed  set  of  state  components,  allowing  whatever 
is  relevant  for  a  particular  system 

As  for  security  properties,  many  people  consider  the  .sole  sig¬ 
nificance  of  the  lh  11  and  LaPadula  model  to  be  I  be  “simple  seen 
illy  piopcity  and  “ +*pl  opci  t  y  \\  e  definite d.V  ih»  Hot  h  t  I  t  Ills  is 

til*’  e:use.  The  model  is  much  more  Complex  than  this  belief  nidi 
cates,  establishing  a  view  of  system  interaction  with  its  environ* 
m*nt  Tin*  concepts  ol  actions,  rules,  and  the  definition  of  whai 
mak**s  a  system  secure  are  fundamental  to  the  model  The  simple 
security  and  ‘-properties  are  only  used  to  define  tin1  secure  state 
predicate  We  allow  a  different  security  predicate  to  be  defined, 
while  maintaining  the  same  conceptual  framework  In  th'.s 
manner,  our  approach  can  be  tailored  to  applications  where  some 
variant  of  the  simple  security  and  ‘-proper!  ies,  or  pci  haps  a  com 
plclely  different  definition  of  secure  state,  is  more  appropu.it r 

However,  defining  security  strictly  as  a  stale  inv.uiaiit  is 
inadequate  to  capt  tire  «uir  intuitive  not  ion  of  security  It  is  mars- 
sniy  to  place  res!  net  ions  on  slate  transitions  as  well  To  provide 
tliu  capability,  we  augment  the  model  s  concept  of  senility  with 
:»  set  ol  ml**  properties  -  conditions  that  must  be  met  by  all  rules. 

The  "tranquility"  property  is  a  typical  example  of  such  a  condi 
t  ion 

3.2.  Defining  System  Functionality 

When  the  state  is  defined,  the  limits  of  what  a  system  may 
do  are  defined,  but  nothing  is  said  about  what  the  system  will 
actually  do  A  framework  only  provides  a  potential  for  certain 
tonus  of  action,  it  does  not  guai  autce  vvliat  will  happen  For 
example,  the  framework  defined  in  Section  1  provides  a  capability 
to  read  in,  process,  and  send  out  messages,  but  it  does  not 
guarantee  that  anything  will  happen  The  framework  only 
requires  that  whatever  does  happen  obeys  the  secui  it y  requite- 
incuts  set  fori  h 

TIi**  functionality  of  a  specific  system  is  defined  by  a  set  of 
rules  of  operation  Hides  ol  operation  are  stale  transitions 
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describing  under  what  conditions  changes  rati  be  made  to  the 
s' ale.  Tilt*  rules  must  completely  capture  all  possible  effects  «m 
the  s, ate  ot  which  the  system  is  capable 

3.3,  Proving  System  Security 

Oim'c  tlu  actual  opri  at  am  of  the  system  is  defined  by  the 
lilies  of  operation.  |(  is  neeessai y  to  eiisuie  that  the  s)sM*iii  is 
secure  In  our  appioach,  two  conditions  in  list  he  satisfied  before 
a  sy  si  mi  can  he  said  to  hive  met  Its  i  ri|Uireinr»ts.  'i  lie  first  eon 
dition  is  that  the  system  defined  must  inn  i  the  constraints 
ih’liiied  n»  the  predicate  "smirc^-yalcm"  and  the  .second  is  that 
the  system  specific  rules  of  operation  meet  all  of  the  rule  security 
plop,  t  ties  Holli  arc  vital  to  eapt  urilig  a  complete  notion  ol  seen 
nt  V.  Sat  islart  ioli  of  the  first  condition  is  shown  by  proving  a 
theorem  stating  tlial  il  a  rule  set  is  eotu posed  of  the  defined  rules, 
ami  if  the  action  srt  is  (lefiiied  from  those  rules,  and  if  the  initial 
state  is  valid,  then  the  system  defined  hy  the  action  set  must  be 
secure.  *1  hr  second  condition  is  met  if  every  rule  defined  hits  the 

specified  ploperty- 

3.4.  Caveat 

'l'h is  approach  has  been  presented  in  a  very  |mear  fashion 
1  lus  will  not  be  t  he  rase  in  practice  'riieie  r  delation  among  all 
three  steps  u  ti  1 1 1  a  complete  model  is  piodlleed  'I'hen.  if  either 
i  In*  system's  requirements  or  functionality  is  redefined  during  the 
development  pro  ‘ss,  the  model  should  be  modified  to  reflect 
those  changes  ami  repioved 

4.  AN  example  ok  the  approach  in  cypsy 

The  idea  of  representing  abstract  model  concepts  in  Cypsy 
is  at  ill  new  to  many  people’s  minds  They  are  used  to  think  mg  of 
Cypsy  sls  dealing  in  more  concrete  terms,  as  is  the  case  in  per- 
toriiiing  code  verification  However,  the  <Iyp  y  spec ificat vm 
language,  being  a  form  of  typed  first  older  logic,  is  sufficiently 
powerful  to  represent  modeling  concepts.  Tins  serf  ion  describes 
the  f cell li lijUes  used  m  our  approach  III  the  context  of  a  Cypsy 
example 

The  '‘sample  we  u*.e  a  simple  message  I  Iter  Messag  *s 
at  rive  at  the  filiri  on  various  incoming  lines,  ami  if  they  pass  the 
security  cheeks,  the  messages  get  routed  to  outgoing  lilies 

We  chose  a  message  filter  as  an  example  foi  our  modeling 
approach  because  it.  is  very  dittcrriit  from  the  traditional  use  of 
Hell  A  l.nPudula  *v>  a  secure  operating  sy.tieiu  model.  The  exam¬ 
ple  illusi  ial»*s  (bat  state  inaelmie  modeling  hi  the  Hell  A-  l.al'a- 
dula  framework  is  appliralde  lo  a  wide  anay  of  security  applna- 
t»“iis  anti  not  simply  scenic  opciutuig  systems 

The  lorinal  model  lor  the  message  fdter  consists  of  four 
Cypsy  scopes  The  FlLTER_Global^Def  mi  Lions  scope 
m'liiiis  the  types  and  functions  used  as  a  basis  for  the  framework 
batch  <>t  the  remaining  three  scopes  corresponds  to  a  step  of  our 
approach,  :us  described  ill  Section  3  tin-  framework  is  defined  in 
the  FILTF.R_Securlty_Pollcy,  tin  system  functionality  is 
delijn-d  in  the  FI  LTER_riu  3  e6__of _^Operat,lcm  scope,  and  the 
^t**Ps  to  pfove  that  the  system  functionality  obeys  the  constraints 
‘-'f  the  Iraiuework  an*  defined  in  the 

FlLTB:R_Rules__Model_Proof  scope 

The  n  mainder  of  this  sect  uni  contains  the  Cvpsy  formal 
spent  icat  ions  for  each  of  these  scopes  English  text  is  inter 
>persed  with  the  llypsy  to  help  the  reader  understand  its  general 


orgwmal toll  as  well  ns  the  mole  subtle  specification  techniques 
Name  importations  between  scopes  have  been  omitted  from  the 
CSypsy  for  the  sake  of  brevity  Other  than  the  omission  of  name 
importations,  the  sect  mils  emit  .tin  a  complete  bating  of  the  Cypsy 
scopes,  which  have  been  piusril  ami  proved  using  the  (.lypsy 
Ye  nf  lent  -ion  Knv .roll men t 

4.1.  Defining  the  Framework 

The  definition  of  the  framework  loi  the  F!l  TFK  model 
begins  m  the  FILTER_GLOBAL_Dtif lnl Lions  scope.  Tin1' 
siope  contains  definitions  of  the  primitive  components  The 
FlLTER_Sucurity_rollcy  completes  the  frutmwoik  by  drfiu 
»ng  the  descriptive  capability  and  the  genera1  mechanism*  of  the 
model 

4.1.1.  Primitive  Components 

This  scope  begins  by  defining  all  of  the  necessary  model 
piimitives  such  as  subjects,  ohjci  ts,  and  the  state  -Similar  elc 
Incuts  of  Hell  .V  FaPadula  appeal  us  comments  on  the  tight  mar¬ 
gin 

ccope  I  1L.1  Ut_G  lubal^Dof  in  it  ions  = 
begin 

•l  l.lemcr.tn  ol  the  rii.Tl.K  )  <  H  t  L  similar  elements  ) 

l  or  the  model  of  a  message  filter,  subjects  are  considered  to 
be  lines  winch  receive  messages  into  the  filter  and  send  mes¬ 
sages  out  The  objects  are  the  mossagos  latch  message 
contains  its  secur l  ty^level ,  sender,  receiver,  and 
contents. 

type  subject  =  line.  <  .s  > 

type  Inc  =  pending. 

type  object  -  mevsage.  (  n  ) 

type  message  -  rccord(i:i  scour  l  ty^leve  1 . 

soi.de  i  lino, 
dest  line 
contents  contents), 
typo  contents  =  pending. 

Security  Attributes  arc  defined  as  m  Hell  A  FaFadnla 

typo  classification  -  pending.  {  C  ) 

type  categoi y_sot  =  sot  ot  category.  {  K  ) 

typo  categoty  =  ponding. 

typo  seem  i  ty  level  =  {  l.  > 

i  oeox  d  (cl asm  f  1  c  at.  ion  clansif  ication  . 
category  set  categoi y  set). 

Junction  dominatCF  (el.  g2  cccui uy  level)  boolean  - 
begin  exit  (r.snumc  result  = 

(  62  classification  lc  si  classification 

*  s2  category  cet.  sut-  si  category  set-)), 
cml . 

Request,  and  declGlon  aie  used  as  in  Hell  A  l.al'adula  to  null 
cate  a  rule  invocation  request  and  the  corresponding  indication  ot 
success  or  failure  The  security  levels  of  subjects  and  objects  are 
defined  as  in  Hell  A*  l.al’adula  with  one  exception  the  security 
level  of  it  given  subject  has  the  potential  to  change,  while  t  In¬ 
security  h-vel  or  a  given  object  cannot  This  view  is  consistent 
with  message  processing,  where  changing  the  security  level  of  a 
message  changes  the  message  itself,  ami  erratics  a  distinctly  new 
message 
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Ij'pt'  I  V  m  I  P  i*  t  =  ptMllilllg. 


i  it  ) 


i  w  } 


type  decision  -  (yen.  no.  audit.),  <  l>  ) 

type  eubject  seem  i  ty  level  =  i  I  ti  ) 

mapping,  f  1  om  subject  to  uetui  ny  ltjvel. 

function  ol*ject_Rl(o  object)  roomily  level  -  i  1.  } 
begin  exit  [assume  result  =  o  si), 
ond . 

(iypsv  ImiII.  i  luslmirs  arc  used  to  d'Mrtbe  the  incoming  :i n <1  out 
going  objects  that  each  subject  cun  access  A  bulb  l  hisloiy 
maintains  a  copy  ot  all  tiaffjc  o\n  a  guru  bullet  The  iinorma 
t  toll  |S  I  ('presented  as  »  sequence  o|  objects.  the  ordel  of  the 
sequence  i  cprrscnt  mg  the  ordri  of  piocrssing  The  bullet  It  is 
tones  replace  the  (siibjoit.  oh  ji  ct .  access)  triple  ol  Hell  ,V  l.al’a 
dula  Historic*  ale  a  n»oie  appiopi  i.itc  iiicaiis  o|  ijescj  1 1» | tt ^  l|i»‘ 
sect]  lily  piopertles  ol  a  message  applicai  i»n  than  access  tuples, 
which  work  bettei  in  the  scenic  opci  at  ing  s\  st  cm  il\ >m  ;ii  n  While 
\\e  have  chosen  to  use  the  concept  ol  bull’ci  histones  in  the 
model,  we  do  not  wish  to  use  t|ir  ( ■  \  psy  !!*('  (in I crproeess  com 

mnnication)  mechanism  Tlir  complexity  of  the  (iypsy  semi  ami 
leecive  inccli  iu isli:s  are  imncecssaiy  |oi  I  he  model 

(buffers)  {  11  ) 

type  buf  f  ot  _h  i  stor  l  ei:  =  mapping  from  subject  to 

bui fet  _histoi y 

type  buf f er_lnsloi y  =  sequence  of  object. 

A  state  is  a  record  structiiic  ol  tin  state  \:irial>les  It  includes 
the  buffer  histories  associated  willi  t  lie  incoming  and  outgoing, 
lines,  as  well  as  the  security  levels  ol  the  subjects  In  older  W* 
keep  the  sccunty  policy  indcpt  :;d«’lM  of  the  concrete  repicsoiita 
lion  iif  the  s#  at  r,  srverjd  »\ti.»eiio!i  fmjel  j.  »|js  ;ij  e  defined  to 
retrieve  Items  front  the  state 

typo  riLTUisiate  -  {  V  } 

l ecoi d ( l ncomi ng  buf for  hi  s;t.or  ion . 

outgoing  but f ci  hint  or les . 
cubjoet^sl  eubj  oct_tucur  lty^lovol)  . 

{  State  Extraction  Functions  ) 

function  )n>  ming  hit;tory(«  uubject.  v  filter  iMatc) 

buf  f  or  _h  i  utoj  y  -• 

begin  exit  (assume  Tesult  =  v  mcomi ngl*) ) . 
end , 

function  o\«tfcoin£_histoiy(s  subject,  v  filter  state) 

buffer  history  ■ 

begin  v.xit  (assume  rosult  =  v  outgoi  ng  I  n] )  . 
end . 

function  eubject_6l(s  subject,  v  liltol  state) 

Seoul l ty  love  1  - 

begin  exit  (assume  result  =  v  subj ecL_sl (s) ) . 
end . 

Act  bins  characterize  the  effects  that  may  take  place  m  the  sys¬ 
tem  An  action  consists  i'f  tour  components  a  request,  a  decision, 
a  starting  state  and  a  resulting  state  A  collection  of  actions 
called  an  Action  Set  aim  is  intended  to  include  all  combma 
t  Kills  ol  requests,  decisions,  new  states,  and  old  stales  The  term 
wset  in  the  security  policy  scope  refers  to  an  action  set  analo¬ 
gous  to  "W  ”  in  Hell  mid  l,al*ad ubi. 


type  Hi  li  on  bvl  --  net  ot  dct-ioii. 
type  adieu  pending 

function  action  iequei;t(ft  action)  request  =  pending 
function  a-.  tioii_d‘’ciK  ion  (a  action)  decision 

p  Mid  i  ng 

function  ac t ion_old_b t ate (a  action)  filtcr_Ptale 

pend i ng 

luiution  act luii^now^iatc  (a  action)  1  1 1 1 ei _s:t  at  e  - 

pend i ng . 

Ifules.  as  del  Mini  by  Hell  aiid  l.al’adula.  an-  ;i  Imn  linn  tioin  ;i 
( i  cq  u  cs| ,  slate)  pan  to  a  ,dccbd*»n.  state)  pal!  Since  pinpiiUes 
must  be  ploVed  al-uit  sets  ol  Miles,  it  |s  dllllelllt  to  IrpliM'ltl 
rules  .is  tiy  psy  lumtioijs  because  (.»>  p**y  docs  not  piov  nle  a  capa¬ 
bility  t«'  1 1  asv'li  about  si  l  s  ,f  aibitiaiy  |iilut|oi;s  Instead.  \\e 
d'duic  lilies  as  a  (iyps\  mapping  Ii<>iii  a  rule  Input-  1<>  a 
rulu  output  H  ii  le  inputs  Itpl.sr'it  a  leqUcsl  and  an  input 
stale  Kill*  oi'tput--  rcpi«-M-|it  a  de«  |s|oli  and  all  output  (lcsiil 
taut)  si  Me  In  ti\ps\  this  means  that  when  a  rule  is  supplied  a 

I  11  lo _ III  1  »U  1  It  let  III  11*-  .1  I  l||c_i»ut  put 

type  rule  -  mapping  1 1  om  iule_  input  lo  lull*  output  . 

{  r  tio  1  11  Hi I.  ) 

type  mle_inpui  r  eroi  d  (request.  r  equo.M  . 

state  !  1  It  ei  ul  at  e) 

function  input  lequert(T)  lule  input)  i  equeu* 
begin  exit  (assume  result  •  r i  request) 
end . 

function  input,  iitate  u  i  rule  jnpuO  filtm  i;tate  - 
begin  exit  (assume  rcsu’.t  -  ri  slate), 
ond 

type  lull*  output  =  i  ecoi  *1  (decision  decision. 

state  1  1 1  lex  st ate) 

function  on  t  pul  dec  i:>  ion  (i  o  rule  oulp.il)  decision 
begin  exit  (assume  result,  =  jo  decision). 

.'-,d  1 

function  output  s'tfttefr  e  rule  output)  1  l  1 1  *  i  mate 
begin  exit  (assume  result  =  to  state), 
end 

end.  i  scope  I  1 1.1 1  It  y.lobaljvt  lnitioiu;  ) 

4.1.2.  Definitions  and  Relationships 

The  tole  of  the  seeiiiily  policy  scope  is  to  hnish  I  he  task  ol  estab 
llslnng  the  model  ‘s  framework.  begun  by  the  global  definitions 
scope  'This  is  done  by  delmilig  hasp  system  concepts.  stieli  as 
what  It  means  foi  a  system  lo  be  seeuie,  and  defining  a  \  lew  o| 
how  eoinponeli Is  work  togelhrl 
scope  ]-‘ l LlbH^Uccut  it  y_ro)icy  - 
begin 

(  name  declarations  omitted  ) 

In  JHellTb  ,  a  systems  (Operation  is  uclincd  by  its  action  set,  \\  . 

'The  act  loll  sol  is  a  COinplotr  |  ept  esent  a!  ion  id  all  possible 
actions  loi  the  system  Smiilarly,  the  eonecpl  ol  a  systcir.,  in  our 
ui*  vbd .  is  captured  by  an  act  nut  .set,  called  wset  In  Hell  and 
I  nl'ad ul.i.  a  system  is  secure  ill  (it  and  only  il)  all  possible  stale 
m  qui  nces  arc  secuic  A  slate  sequence  is  seeuie  ill  every  stale  in 
l  lie  sequent  c  is  a  seeuie  state  'Thus,  a  system  is  seeuie  iff  every 
leatli  able  stale  is  sec  lire  Our  definition  of  GeCUl'Q^pystem 
ca  pi  u  i  es  the  same  Cv'iiecpt  by  stating  that  for  any  stale  tha*  is  a 
Valid  state,  that  state  must  be  secure. 
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Iiir.ction  FiiiiiM1  ey  Rt.em(W'»el  niiun  srl. 

7.0  1  J 1 1 Pi  _i>lal  c)  boolean 

bet 111  exit  ( assume  result  ill 
all  v  tiller  state. 

van  a  state  (v.  vm-t.  70) 


iii’CUi  *•  :;t  i\.v  ,  )  )  . 


eini . 


oCt'Ul  C  L'babC  1 1 «'  I  Hies  what  H  HK'Siir'  b’l  a  Male  tv  be  smite 
In  tlir.  ease,  loi  all  vbjctls  and  subjects,  il  an  obj* at  t''  ill  the 
outgoing  lilst*M\  of  some  su  lijri  I  in  ill*'  state,  I  II  ■*  li  I  lie  piopel  t  irs 

lapioMil  l»)  sccuiity  checks  made  mihi  h-dd  These  pi  . 

|M ||  u>  :i|r  |||. if  flu-  ol'jn  1  in  n  si  l»r  III  some  subject  s  1 11  ii  >11 1 1  li>‘, 
build  li |sf  i if  y  and  lll.it  the  senility  level  o|  I  In  olijei  1  dom 

male  1  In-  seen  l  il  y  level  o|  I  lie  I  ccciving  subjci I  l  ilt  I  In  l  in«*le.  I  In- 
seen  1 1 1  \  level  o|  l|ie  expol  I  mg  subj*  *  t  lnuM  dominate  tii.it  of  the 
object 

Junction  seOUI  e_j:t  at  o  (v  1  l  It  ei  _i;l  at  »:) 

boo  1 e&n 

big  in  exit  (assume  result  lit 
all  obj  ob) or t 
ail  sending  cub)  subject 

obj  in  outgoing  Ji  i  u  tor  y  (sending  sub  j  v) 


security  cheoki.__maue  (obj  send  ing  nubj  v)). 


end . 


Junction  upc  ul  It  y  _e  hocks  _ma<1e  ( ot  j  ot.j»*et. 

semi  i  tit  Kubj  subject, 
v  t l l to i _m at o)  boolean 
begin  exit  (assume  result  iff 
some  r  cep  i  vinp,  sub]  subject. 

obj  in  incoming  lust  oi  y  (i  ecel  v  i  np,  subj  .v) 
t  dorai  nates  ( f.jbject  sl  (send  i  i»t  .  v) 

objects  1 (obj ) ) 
a  doiai  nates  (object  si  (obj). 

. .  ..  1  . .  .  .  ..Ml 

V  A  V  V  V  X.  A  .  .  "C»  J  •  '  *  •  • 

end  . 


Valid  pLabe  defines  tin*  \alnl  slates  of  tlr-  system  A  valid 
slate  is  any  st  ale  w  Im  II  is  eit  liei  I  he  mil  l.il  st  at*  .  «‘i  I  lie  new  si  ate 
in  some  art  ion  in  the  art  ton  set 


junction  vali<l_state(n  fjltei  state. 

wset  action  set. 

7.0  J  life  instate) 

bool ean 

begin  «-xit  (assume  result  ill 
(r.  7-0 

oi 

(some  a  action, 
a  in  wsot 

#n"  ai  tion_new  slat  e  (a) )  )  )  . 

end , 


The  ba6lc_securlLy_Lhcorcm  states  that  a  system  is  secure 
iff  till-  in'll. Ml  set  is  secure  ami  the  initial  state  is  secure  ’I  Ins 
demons!  i  at  es  that  the  system  ran  he  proved  secure  by  proving 
I  hat  all  art  loll'  an*  seen  re 


lemma  basic  security  theorem  (wsot  action  set. 

zO  1  liter  state) 


sccur  c_sysTc.'in(wsci  .  70) 
if  l 

(  seem  p_state(/.0) 

#  secure  action  set(wset)). 


function  secure  action  set  (went  action^set) 

boolean 

begin  exit  (assume  result  li: 
all  a  action . 
a  in  wsot 


secure  statoiaction  now  state(a))). 


Huh  M-i  uiily  propel  ties*  an  i\  mechanism  for  filing  in  the  gap** 
that  a  set  me  state  invariant  *  annul  address  'I  lies*  properties 
air  ixpicsM/d  by  a  pan  ol  functions  III*’  hisl  lunclum  *l*‘lin»'s  a 
*■  *n-l  i  am  t  on  si  ini*  set.  namely  that  each  rub’  m  Ih*-  set  possess 
Si  tin  r  pi«tpi  rt  V  !  lie  s*'*  olid  1 11  ri  *  t  I*  'll  dellhrs  fins  piupelty  1**1  nil 
individual  i  n  It  In  the  i  :v><‘  *  *1  I  11-11  H  .  t  h  •  I  e  an-  t  h  1  ee  1  U  le  m  CU 
l  it  y  |'ii » p *  1 1  les 

Sccui  c_tsbabc_pi  esci  v  mg_i  ul c__fo b  is  us*  d  to  piovc 
secui  o  cy  stem  A  luhsct  b  mi  mill  pies*  i  v  mg  il  and  only  il 
every  lilh  is  security  plcscivmg  A  Idle  b  seelillty  plcsciimg 
when.  Im  e\«iy  input  output  pair,  the  output  slate  is  senile 
wheinvri  the  input  state  |s  ».rni  i  c 
type  lu  le  set  -  Set  o  1  r  U  l  «* 

1  unction  spcuip  state  pi oroi v i ng  i u le  bol (i k  rule  net) 

boo! eau 

leg  in  exit  (atsarce  result  ill 
aM  >  rule 
r  hi  ik 
> 

Recur p  si ato_p! esei v l ng_l u 1 e ( i ) ) 

end 

t  un*t  ion  secure  state  pieseiving  rui*’  (*  i  *.!»•) 

boolean 

begin  *'  x  1 1  (assume  result  ill 
all  r  i  rule  input 
a.  1  ro  rule  out  put. 

(  i  l  i  i  1  i  *' 

t  secure  at  ate ( tnpuiRtat e(i  i))) 

-  > 

rpi  m  estate  voU  put  j: t  at  e(r  o) ) )  . 

end 

The  I  i  a  ii  i|ii  1 1 1 1  y  propeity  is  a  classic  example  *»l  l  In  piohlcius  with 
reiving  ei >m pie* rl\  on  slat*-  invariants  !<■  presiiv*'  a  desired  ''on 
I  epl  o|  seen  illy  Without  this  a  reijn  il  cineli  I .  the  senility  levels 
ul  subjii'ts  ran  be  manipulated  to  ‘sitis|\  flu  sciiire  slat* 
reipill  <*  Mi  <4  ll  Is.  without  *on!uimilig  l»*  llic  intended  hehaviol  III 
this  system,  anile  set  i>  t  rampi  ilit  y  pt  esrrv  mg  iff  n. .  r  nles  i  hang* 
a  subject  s  seem  it  y  lev  *‘l 

I  unction  tr  anqe  l  1  l  ty_pi  »'set  v  i  ng_t  u  l  e_bct  (is  r  u  1  %’  set) 

t»oo  1  pan 

begin  eXK  (assume  result  lit 
all  r  rule, 
r  l  n  r  s 
-  > 

U  anqu  1 1  1 1  y  pr  rt;er  v  l  ng_r  ul  *»  ( r  )  ) 

pud 

I  unci  10*1  t:  anqu  1 1  i  ty_j»i  or  or  v  i  ng^i  u  1  *•  u  rule) 

boolean  ‘ 

begin  exit,  (assume  result  it  I 
all  ri  rulc_input. 
all  r  o  rule  output, 
al 1  subj  nubj  ect . 

I  li  1  ]  =10 

-  > 

subject  _sl  (sut'j  i  nputs  tate  (i  i ) )  - 

sub j oct_s  H  subj  out pu testate (r  ol ) ) . 

end 

A  rule  s«‘l  is  buffer  history  preset  viiig  tf  and  only  'I  non**  *»l  the 
rules  art  able  to  remove  objrrts  from  any  buffer  histories  1  Ins  is 
ro'cessaiy  1*'  ensure  that  the  bufl’er  histories  we  have  defined  roil 
form  t*>  the  semantics  of  Uypsy  buffer  fust*>ru*s  Without  such  a 
reipnrcment .  a  rul*-  c*nil*l  “satisfy"  the  conditions  o!  secure  state 
by  simply  rewriting  l lie  buffer  history 


function  l>ui  f  *i  _hiBloi  y_j»i  9B«t  v  mgr  u  1«*  pet  (if 

lule^iet)  bool emu  - 

begin  9X1*  (asBumw  i esult  Ilf 
pl  1  i  rule. 


but  i «r _hielor y_pt  eaei v l ng  i  il e ( i ) ) . 


function  bu  f  f  ei  _h  l  b  to!  y  pt  eser  v  l  ng^t  u  le  (!  rule) 

boolean  - 

begin  exit  (assume  result  iff 
all  r  i  rule  input 
Pl  1  r o  rule  output . 
til  6ubj  subject, 
til  o  object, 
r  lr  i J  -  r  o 
-  > 

incoming  hibtoiy(Ku*jj  mput^Btate  (» i ) ) 

incoming  hnstoi y (subj  out put_ ettto (» o) ) 

A  (o  in  outgoiiig_tiistci  y  (tub) .  input  (r  l ) ) 

-> 

o  in  outgoing_hiBtoi y (pubj .  output  state (r o) ))) . 


'i  h <-  thror-m  socur  c_rul©8_f  orfti_6ccur  o_ey  stem 
corresponds  to  the  llcll  ami  I . :i  1 1  ;i«l u  1 .1  ior«*l|,it>  VJ  Till''  deim'li 
Mint's  that  a  system  call  !»c  proird  vnir*'  l»l  pi"l  Ulg  that  all  IW 
ci «i  respond mg  i  uh  >  an  sn  me  It  senes  as  a  link  I'ctwc'n  t  li *• 
concept  oi  defining  a  system  in  term"  of  an  :uii*'ii  set  and  delm 
mg  the  I unct lonaht \  **l  a  p.iiti'iilai  system  in  terms  ol  mles  ol 
op*  rat  imi 

lemma  secui  e_i  ult’b^f  or  o^i.ecui  e^syBttfO  (is  rule  net 

wu**t  action  set 
70  1 1  ltd  state)  = 

(  act  lonuet  del  l  ved  1  r  o®  :  u lc*;  ( r  c  wset.  zO) 

A  cecur  o_Ftate_  pi euer ving_i  uio_set (i  s) 

*  *:oc ur  s~c tite  CzO) ) 

-  > 

secur e_6ysteo(wset  20)  . 

All  act  I*  »n_s«ip|ence  IS  a  sequence  ot  actions  produced  l»\  OMimcii 
tl\c  appln  at  ion"  ul  I  lllrs  This  ty  pe  Is  |in(  <|  | r «•»  1 1_\  required  in  th* 
ni'slrl.  I*'ji  si  f  n  es  to  pr«>\  ulr  a  link  l»ri  \\ rt  n  an  acti«*n_si  t  amt  a 
mh-^set  A  pal  tuular  a*  t  ioli  st  qiieiit  e  ties*  lilies  one  path 
ihiough  th*‘  action  set.  chosen  I •  \  the  selection  ol  rules  and 
requests,  and  resulting  Hi  a  stqile;  t*  ol  (decision,  new  slalej 
pairs 

type  action  sequence  '  sequence  of  action 

All  liCtjon_sct  |s  drilled  I'loln  a  rilh‘  set  ||l  defy  action  III  the 
action_set  in  in  an  siriion  sequence  \thnh  starts  with  tin-  initial 
slat*'  and  has  hecli  denied  I  loin  th*1  rule  set 

function  act  ion_tie  t_doj  l  ved^f  i  om_l  u  1  e6  (is  rule  set 

wset  action  set 


zo  f  liter  st  ate) 
boolean  " 


begin  exit  vassume  result  ift 
all  a  action 


Borne  aseq  action  sequence, 
a  in  a b e q 

A  asoq  r.e  n u  1 1  (act  ion  sequence) 

A  action  oldctate (f li st (arieq) )  =  70 
A  action_6oq_doi  ived_f  r  om_r  u'.oslis 

non last (aseq)  . 
1 ast (aneq) ) )  . 


defiled  1 1  "111  th*  ml*  set  'I  hi"  fr»  limit  definition  lilik"  ra*  h 
n<  1 1*  <11  III  th*  srip.li  hie  togellnr 

function  action  seq  del  ;  ved_l  i  om_  r  u  1  es  (r»;  »ule  set. 

asev,  action  sequence 
a  action)  boolean  • 

begin  exit  (assume  resul*  iff 

(  action  dot  wed  f  i  otn  r  u 1  op ( r  s  a) 

A  (aseq  nv  nu  11  ( ac  t  lonRpquotice) 

-  > 

(  action  new  state (last(aFeql)  s 
action  old  state (i) 

A  ac  t  lon^aeq  d«‘i  l  ved  Mom  rules (te 

neniast Caseqi 
last  (asoq)  ))))). 


An  :«<  1  o  >n  In  del  ii  ed  1 1  ■  *m  a  r  ti  It-  set  l !  *  I  liei  e  is  a  in  Ic  W  h  u  li  when 
supplied  a  ml*  input  t  *>r  responding  to  the  a*  turn's  iiqueM  and 
old  "tale,  it  t  tn  ii"  a  r  ule  <  >ut  pu  l  that  «vu  esp.  *iu|s  w  .1  h  tin  a*  1 1  >h" 
tlei  ini. »n  and  new  >i ate 

function  t<.  t  iori^do:  i  ved_  1 1  oji  i  u  1  et  (is  rule  net. 

a  act  ion) 

boolean  - 

begin  exit  (assume  result  iff 
Korno  i  rule 
some  ii  rule  input 
some  i o  » u 1 e  output 
r  in  if 
A  I  |  T  1  ]  =  I  o 

A  input  state  (r  i)  =  actioi.cld  state‘a) 

A  input  request  (ii)  =  action  request  (i.) 

A  out  put  _de ■;  i  s  ic n  ( i  o)  =  action  dec  is  ion  (a) 

*  output  sute(ro)  =  act  loniicwstate  (a)y 

end 

This  I*  mm.*  I"  i|Ulle  Miuilai  to 

Recure_rulet»_f orm^BOcui  e  syctom.  l»-ii  deaK  w,tl:  a*n.*n 

seqil*  li>  «>  instead  *  >1  a*  t  |oh  s,ls  'IIiin  hinliia  srlirs  i.»  aid  the 
pi-s*t  o|  theothei  lemma  1  h is  in  an  example  ol  pi«i.*t  in«>dui.u  1 1  \ 
Hi  <  ii  pN» 

lemma  secui cm u lent oi ®__i;ocm e  actior_seq 

(is  rule  set 
aseq  at  1 1  oi.  sequence 
70  f  i  ltd  _st  ate)  - 

(  aseq  ne  null  (a.  Won  sequence) 

A  action  old  st  ate  (f  imt  (asoq) )  70 

A  action_seq  del  1  ved  I  t  oiti  i  u  1  es  ( I  s 

non  1  ast  ( a»o  q> 

1  a  s  1  ( a  s  e  q ) ) 

A  secure  state  preserving  rule  set  (is) 

A  secui o_6t*’ v (zO) ) 

-  > 

8 e c u I  «*_ a e  1 1  on_S e q ue no v  ( a s eq ' 

An  a.  t  a  »li_scq  1"  set  u » *  ill  tin  pew  MO,  v  ,|  ,  \  ,1  \  a>  I  n  ’It  |s  >t  1  u !  * 
function  seen 1 e  act  ion  sequence  (asoq 

ac  t  loe^soqi.i  nee ) 
bool oan 

begin  exit  (assume  insult  l!J 
all  a  action 


secure  st  ute  (act  ior._ncv  sta'e(a))). 

end 

III  *•  lemaiiiiiig  leminaN  are  t .  •  proie  that  th*1  d'f  in  it  i*  »n  >»!  dom 
mates  r.i  the  1  u« ul I  "aii"li*N  th*  paiiid  oideimg  nipm * meiit n 
»»t  I’eiiig  n  l  l*  \i\  *■  ant  |n\  in  m*  1 1  p  .  and  1 1  an>it  11  e 


An  action  sequence  is  denied  froin  a  iule_set  ill  the  last  a»  li«*n  i> 
denied  lit*tn  the  rule  set.  It r-  *»ld  stale  i"  the  Naim  a*,  the  new 
state  ut  the  preiioijN  action,  ami  the  lest  ol  the  act  i«»n_Nrqurm  «-  |n 


lemma,  doroi nates^is  reflexive  (g  Gecunty_level)  = 
dominates  (s ,  s)  . 

lemma  dominates  is_ant l symmetr l c  (sl,s2  security^ level)  = 
(  domi nates (s l .  e2) 
ft  domi nates (s2 .  si)) 

-> 

si  -  s2. 

lemma  dominates_is_t.ransi txve  Cel. 

s2.  s3  Becur ity_level)  = 

(  dominates(sl .  s2) 

9  dominates (s2 .  s3)) 

-> 

dominates (si .  s3) , 

End.  {Fi lter^Secur ity_Policy> 


4.2.  System  Functionality 

The  Rules  of  Operation  scope  defines  the  functional¬ 
ity  of  l iu*  system  by  stating  properties  of  a  valid  initial  state  and 
enumerating  all  state  transitions.  These  properties  must  then  he 
proved  to  be  secure  with  respect  to  the  security  policy  described 
in  section  4.3.  This  example  makes  some  simplifications  to 
minimize  the  size  of  the  specification.  First,  there  is  only  one  rule 
of  operation,  called  process_message.  For  other  applications, 
our  approach  can  be  generalized  easily  tc  a  larger  number  of 
rules.  Second,  the  specification  assumes  that  the  incoming  buffer 
history  is  pre-established  at  the  initial  state,  and  remains  fixed 
for  the  duration  of  the  execution  of  the  filter.  This  assumption 
allows  us  to  avoid  creating  a  rule  to  describe  how  a  message 
arrives  at  the  filter.  Despite  the  assumption,  the  specification  is 
still  completely  general,  since  we  prove  the  seen  lily  of  the  filter 
tor  any  arbitrary  incoming  buller  history- 
scope  KlLTER_Rulcs_of_Opcration  = 

begin 

{  name  declarations  omitted  > 

A  valid  initial  state  for  the  message  filter  is  defined  by 
lnitlal_f llter_sta.te.  A  stale  ZO  is  a  valid  initial  filter 
stale  iff  no  messages  have  been  sent  out  on  any  outgoing  lines, 
anil  the  internal  mappings  are  defined  for  all  lines.  jNo  restric¬ 
tions  are  placed  on  the  incoming  buffer  histones  at  initialization 

function  initial  filter  state(zO  f l 1 terstatc)  boolean  = 
begin  exit  (assume  result  l £ f 
all  outgoi ng_l l ne  line, 
all  1  line. 

zO  outgoing  [outgoi  ng_l  me]  -  nu  1 1  (b«jf  f  cr_h  istory) 
ft  1  in  domain(zO  incoming) 

9  1  in  dorna,'n(zO  outgoing) 

9  1  in  doroa;.i(zO  subj  ec  t_s  1 )  )  . 
end . 

In  tins  simple  example,  we  have  only  a  single  rule  of  operation  A 
complex  system  would  have  many  more,  ail  written  m  a  similar 
style  Frocees_inessa.ge  rule  is  defined  as  a  constant  (a 
function  with  no  arguments)  of  type  rule  The  rule  is  defined 
by  comparing  it  with  a  corresponding  specification  function  called 
process  message.  The  definition  of  the  rule  says  that  the 
mapping  returned  by  proces6_message_rule  matches 
process  message  for  every  input /output  pair  This  approach 
allows  us  to  make  the  con ncet mu  between  an  arbitrary  set  of 
rules,  as  the  policy  uses,  and  an  instant iati#>n  of  a  particular  set 
of  rules  for  i he  system  being  specified 


function  proeess_meF6agQ_rule  rule  = 
begin  exit  (assume 
all  ri  rule_inpwt.. 
all  ro  rule_output. 
rcsultfn)  =t  ro 
iff 

pi ocesc_me66age (r l)  =  ro) . 

er.J . 

The  function  process  message  describes  the  functionality  of 
the  system  at  an  abstract  level.  The  function  describes  the 
rule_cutput  (f  ilter_state,  decision)  that  it  will  return 
given  any  rule__lnput  (f  llter_state,  request).  The 
function  must  be  well-defined  to  prevent  unsoundness. 
Process_meGsage  says  that  if  there  is  a  message  which  is  an 
element  of  some  incoming  line’s  buffer  history,  if  the  security 
level  of  some  outgoing  line  dominates  the  the  security  level  of  the 
message  and  if  the  security  love!  of  the  message  dominates  the 
security  level  of  the  incoming  line,  then  a  new  f llter_state  is 
evented  by  adding  the  message  onto  the  outgoing  line's  buffer  his¬ 
tory  of  the  old  fllter_ state,  ami  the  decision  is  yes.  If  any 
of  these  checks  arc  not  met,  the.i  the  decision  is  no  and  the 
resulting  filter  state  is  unchanged.  This  specification 
makes  no  attempt  lo  describe  how  the  next  message  to  process  is 
determined,  or  how  the  message  is  routed  to  a  proper  outgoing 
line.  In  this  specification,  request  is  nev?r  used.  It  is  assumed 
that  the  rule  is  activated  upon  arrival  of  a  message. 

function  procesp^mescage  (n  rule  input)  rule_output  - 
begin 

exit  (assume 

some  m  message. 

some  old_srate  f ll ter_s tate . 

some  incocn  ng_l  me  outgoing^  me  line. 

Old  Ct**  *  2  ”  n  o 

9  ;i  id  in  ol d_state  incoming [incomi ug_lme] 

9  dominates (old_stato  subj  cot_sl  [outgoing_l  me  j  . 
m  si) 

ft  dominates (ms]. 

old_stat»i  subj  ect_sl  ( incoming_l  me]) 
then  result  state  =  old_state  with 
(  outgoing  (outgoing_l  me]  = 

old_f> tate  outgoing  |.outgoing_l  ine]  <  m) 
ft  result  decision  =  yes 
else  result  state  =  old_st,ate 
9  result  decision  =  no 

f  l)  . 

end.  {  FILTER_Rules_of_Oper ation  ) 


4.3.  Proving  the  System  Secure 

The  object  of  the  scope  Fllter_Rules_Model_Proof  is  to 
establish  that  the  rules  of  operation  in  the 
Fll ter_RulCB_of_0peratlOTi  and  the  system  that  tluy 
define  are  secure.  It  brings  tl. •-  pieces  defined  in  various  scopes 
together. 

scope  F ILTERRu les_Modei  Proof  = 
begin 

i  name  declarations  omitted  > 

The  lemma  securc_FILTER  is  the  main  theorem  to  establish 
I;  demonstrates  that  the  system  defined  by  the  set  ol 
FILTER_operatlon_rules  is  secure,  as  defined  by 
secure  system  This  is  done  by  showing  that  if  an  action_sel 
is  cicated  out  of  the  rules  and  the  initial  state  is  valid  as  specified 
in  the  rules,  then  the  resulting  system  is  secure. 
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lemma  secure  FILTER  (zO  FILTER_state)  = 
all  wseL  actiorjet, 
all  rs  rule_set. 

FI LTER  cpe rat ion  rules  (rs) 
t  actioncctder ived  from  rules(rs.  wset,  zO) 
t  initial  _FlLTEH_state  (zO) 

-> 

i5ecure_system (tfset .  zO)  . 

The  remaining  theorems  deal  with  the  “auxiliary”  security  pro¬ 
perties  defined  by  the  rule  security  properties.  These  must  hold 
as  well  for  the  system’s  behavior  to  be  truly  restricted  in  the 
desired  manner.  TIk  theorem 

tranquility  preserving  FILTER  demonstrates  that  the 
FILTER  Rules  obey  the  model’s  tranquility  property. 

leama  tranqui  1  lty  presei  vmg_FILTER  = 
all  in  rule_set.. 

KILTER  operation  lules(rs) 

-> 

tranquil  ity_preser  vi ng__ruie_set. (re) . 

This  theorem  demonstrates  that  the  FILTER  Rules  obey  the 
model’s  buffer  history  preserving  property.  The  rules  specified 
obey  constraints  on  how  the  buffer  histories  arc  changed 

lemma  Duffer  liistory_prescrving_KILTER  = 
all  re  rule^set. 

FlLTER_operation_rules (rs) 

-> 

buf fer_ history  preservmg_rule_6et(rs) . 

A  rule  set  is  the  set  of  FiLT  R_operation_juIcs  iff  every  rule  in 
the  rule  set  is  one  of  the  enumerated  rules.  Writing  this  theorem 
involves  enumerating  every  rule  of  operation  defined.  FILTER 
has  only  one  rule,  so  in  this  specific  case  there  is  no  need  to  use  a 
set  of  rules.  We  do  so  here  in  order  to  make  this  specification 
easy  to  generalize  for  an  arbitrary  number  of  rules. 

function  FILT£R_oppration_rul es(rc  rule  set)  boolean  = 
begin  exit  (assume  result  iff 
all  r  rule, 
r  in  rs 
iff 

r  -  process_mnssage_r ulo) . 

end , 

end,  {  FILTER_Rule5_Model_Proof  > 


examples  of  such  restrictions. 

We  hope  that  others  will  be  interested  in  adapting  this 
approach  for  their  own  use.  The  general  Gypsy  framework  that 
we  have  provided  will  allow  others  to  conceit  irate  on  the  develop¬ 
ment  of  the  specific  security  propci  tics  and  rules  of  operation  for 
their  own  system. 
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5.  SUMMARY 

We  have  presented  an  approach  for  developing  formal  secu¬ 
rity  models.  The  approach  is  in  the  style  of  Bell  and  LaPadula, 
to  take  advantage  of  user  familiarity,  but  it  is  flexible  enough  to 
be  adapted  to  a  wide  variety  of  state  machine  models.  As  in  Bell 
and  LaPadula,  our  approach  consists  of  three  steps:  a  frame¬ 
work,  which  defines  the  security  policy,  an  abstract  view  of  uys- 
tem  functionality,  which  defines  the  rules  of  operation;  and  a 
system  security  proof,  which  proves  that  the  rules  of  operation 
arc  consistent  w»th  respect  to  the  security  policy  Several  exam¬ 
ples  of  this  approach  have  been  written  and  proved  completely 
within  the  Gypsy  Verification  Environment.  As  far  as  we  know, 
these  a1  e  some  of  the  only  examples  of  complete  automated 
proofs  faithful  to  the  Bell  and  LaPadula  style. 

The  insufficiency  of  a  slate  invariant  approach  has  been  dis¬ 
cussed  by  McLean |McLcan87|  and  others.  Our  approach  allows 
one  t.o  write  further  restrictions  on  state  transitions  to  ensure  a 
sound  approach.  The  Gypsy  specification  in  the  last-  section  con¬ 
tained  lemmas  called  tranquil lty_preserving_FILTER 
and  buff  er_r»istory_preBervlng_FILTER,  which  arc 
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ABSTRACT 


ORI/INTERCON  Systems  Corporation  has 
encountered  numerous  mission  needs  for 
secure  database  management  services 
offered  in  a  practical,  deployable, 
supportable  system  configuration.  Our 
response  has  beer,  to  design  a  multi-level 
secure  system  that  combines  the 
contemporary  archi t ectu^al  notions  of 
security  kernel,  integrity  lock,  and 
trusted  filtering  and  embark  on  an 
implementation  program  using  existing 
products,  technologies,  and  techniques. 
The  INTERCOM  Trusted  Database  Management 
System  (TRUDATA)  project  is  targeted  at 
an  initial  31-level  system  with  an 
ultimate  B2  version  an  the  eventual 
goal.  Thla  paper  describes  the  "Journey" 
that  represents  the  TRUDATA  project, 
including  summaries  of  its  development 
guidelines,  system  architecture,  security 
policy,  and  implementation  status. 


mode  of  operation. )  Ae  processing  and 
reporting  needs  multiply,  this  technique 
forces  duplication  of  process},  ng  power 
and  data  (to  handle  varying  combinations 
of  data  sensitivity  and  user  clearances) 
and  prevents  an  effective  flow  of  derived 
intelligence  data  to  those  users  who  have 
a  subset  of  the  clearances  and  accesses 
involved  in  the  data  pool.  The  net 
results  are: 


1  ; 


Experts  i  ve 
dupl icated 
process 1 ng 


dedicated 
Intel 1 i gence 
environments . 


and 

data 


2)  An  inability  to  deliver  or  make 
available  all  the  relevant 

Intelligence  and  C3  product  and 
uttU  to  al 1  the  users  vho 
legitimately  need  such  data  and 
are  authorized  to  receive  it. 


WHY  THE  JOURNEY  IS  NECESSARY 


Nearly  every  intelllg 
processing  and  C3  system  depe 
ready  availability  of  accurate 
data.  Moreover-  for  "produc 
intelligence  environments,  the 
the  product  is  typically  fost 
comprehensiveness  of  the  data 
jt  was  generated.  The  conge 
twofold : 


ence  data 
rule  on  the 
and  timely 
tion  cycle" 
quality  of 
ered  by  the 
from  which 
quences  are 
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The  combination  of  these  consequence* 
results  in  collections  of  data  of  varying 
sensitivity.  To  date,  the  only  way  to 
provide  a  satisfactory,  data  processing 
mechanism  for  such  collections  of  data 
having  multiple  levels  of  security 
classifications  is  to  dedicate  a 
processing  resource  to  the  highest 
sensitivity  of  any  data  which  might  be  in 
the  collection,  and  then  isolate  that 
processing  resource  from  all  users  who 
themselveB  do  not  havo  clearances  to 
access  all  data  potentially  in  the  data 
reservoir.  (The  so-called  "system  high*' 


WHY  WK 1  RE  MAKING  THIS  JOURNEY  NOW 

ORI/INTERCON  has  a  long  history  of 
secure  system  development  within  the 
intelligence  and  C3  community.  Pursuit 
of  natural  opportunities  within  those 
communities  brought  us  face  to  face  with 
several  programs  and  procurements  which 
had  compelling  requirements  for  MLS  DBMS 
services.  As  we  researched  ways  to  solve 
these  requirements,  we  found  very  little 
in  the  way  of  practical ,  existing 
foundations  upon  which  to  base  a 
solution.  After  surveying  the 
contemporary  technological  terrain,  we 
decided  that  conditions  were  now  right 
for  our  own  expedition.  Right  from  the 
start  we  determined  that  our  destination 
wao  the  delivery  of  trusted  DBMS  services 


in  a  *ruly  useful  implement,  at  i  on .  In 
effect,  we  have  three  "passengers"  on  our 
Journey.  all  of  whom  must  reach  the 
destination  together  in  order  for  our 


trip  to  be  successful.  Our  "passengers" 
are : 

1)  Doctrinal  Security,  i.e.,  TRUDATA 
must  be  secure  in  accordance  with 
DOD  policy  and  regulations. 

2)  Capability,  i-o.,  TRUDATA  must  be 
capable  of  servicing  reil 
operational  missions  in  a  manner 
much  like  a  conventional  DBMS. 
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3)  Achievabili ty,  t.e.,  TRUDATA  must 
be  roable  using  present -day 

products,  technologies,  and 

techniques , 

Four  conditions  convinced  us  that  the 
road  to  that  destination  could  be 
traveled: 


of  certification.  This  combination 
of  talent,  products,  and  services 
gives  us  a  ready-made  support 
organization  for  the  TRUDATA  MLS 
DBMS. 


TRAVEL  PREPARATIONS 


1 )  The  Legacy  of  Previous  Explorers 

Kor  over  a  decade  now,  researchers 
have  been  seriously  exploring  what  it 
means  to  be  a  "secure  DBMS'*.  The 
landmark  Air  Force  Summer  Study  at. 
Woods  Hole  in  1582  ([31.  [5]) 
summarized  the  "state  of  the  problem" 
and  projected  three  architectures 
that  offered  near  term  potential  for 
supporting  trusted  DBMS  services. 
Much  additional  work  has  been  done 
since  then  to  find  productive  paths 
to  trusted  database  services  (e.g., 
[2],  [93.  [173.  [18],  [191.  [20]). 


As  for  any  Journey,  good 
are  crucial  to  reaching  your 
on  time  and  safely.  Six  main 
guidelines  have  controlled 
development  project. 
Journeying  motif. 

These  guidelines 

preparat ions : 


preparations 
destination 
"traveling" 
our  TRUDATA 
In  keeping  with  our 
we  have  paraphrased 
as  road-wise 


1)  Know  what  the  end  of 


should 
arrive ; 


look 

have 


like 

good 


the  road 
before  you 
scouts  to 


anticipate  your  arrival. 
Interpretation 


2 )  The  New  Traveling  Vehicles 

Computer  system  product  advances  that 
have  occurred  since  the  Summer  Study 
make  today  the  right  time  to  move 
trusted  DBMS  technology  beyond 

theoretical  explorations  to  pragmatic 
Implementations.  These  product 

advances  represent  new  modes  of 
transportation,  i.e.,  new  "vehicles", 
in  which  to  travel  the  rood  toward 
trusted  database  management  system 
Of  particular 

are  the  "near" 

of  certified  secure 
well  known  operating 
the  maturity  of  the 


development . 
importance 
availability 
versions  of 
systems  and 
databo.se  machine. 

3 )  The  Reward  at  Journey's  End 

Perhaps  the  most  difficult  traveling 
condition  to  gauge  is  the  market  for 
a  trusted  database  management 

eysten.  While  we  believe  that  such  a 
produi  t  is  not  the  next  "Mustang"  or 
"Taurus",  we  likewise  believe  that  it 
Is  also  not  the  next  "Edsol"  or 
"Cor-vair".  However  measured,  our 

market  surveys  give  us  reason  enough 
to  follow  this  road  to  system 
development , 

U  )  Good  Traveling  companions 


To  succeed  as 
multi-level  DBMS 
must  be  deployable 
well  as  offer  secu 
convenient  and 
Spurred  on  by 
OR I/INTERCON  Sy 

( INTERCON)  has 
Database  Managmen 
development 
Britton  Lee,  Inc. 
and  support  a  pra 
functional  Multi- 
targeted  ultimate 


real  solution  to 
problems.  a  system 
and  supportable  as 
re  DBMS  services  in 
efficient  ways, 
this  recognition, 
stems  Corporation 

formed  a  Trust  ed 
t  System  (TRUDATA) 
alliance  with 

and  AT&T  to  build 
ctical.  deployable. 
Level  Secure  DBMS 
ly  at  the  B2  level 


Have  an  implementation  approach 
in  mind  from  the  very  beginn 1 ng . 
Make  sure  that  implementation 
questions  are  resolved  as 
security  policy.  system 
architecture.  and  assurance 
techniques  evolve. 

2)  Use  a  good  compass  to  stay  aimed 
in  the  right  direction. 

In  lerpre tat  ion 

Use  a  real  operational  mission 
archetype  as  a  constant  backdrop 
for  development  of  architecture, 
policy.  and  actual 
implementation.  Reconcile  all 
design  decisions  to  the 
fundamental  question  "Can  the 
mission  be  fulfilled  under  this 
design?" 


3)  Watch  out  for  "ambushes*' 
every  direction. 

Interpretation 


from 


Balance 
requirement  s 
opera  t ional 


"theoretical" 
against  practical 
requirements  and 


standard  operational  protections 
as  a  tradeoff  mechanism  in 
security  policy  development. 
Keep  the  policy  from  becoming  so 
trivial  that  it  is  meaningless  or 
so  exotic  that  it  is  not 
imp 1 ement able  in  some  practical 
sense . 


)  Don  f  t  st  ray 
beaten  path. 


from  the 


Interpretation 

Base  the  architecture  on 
gen  era 1 1 y  recognized  and  accepted 
techniques  for  achieving  trusted 
DBMS  services.  Combine 
techniques  to  reduce  or  eliminate 
known  vulnerebl 1  it ies. 


20? 


5)  Start  with  a  reliable  mode  of 
transportation. 

Interpretation 

Start  with  an  already  trusted 
product  (operating  system)  as  the 
basis  for  extending  an  existing 
TCB  to  support  trusted  DBMS 
services . 

6)  Stay  in  contact  with  your  base 
camp  and  mark  the  trail  well  as 
you  go. 

Interpretation 


acknowledged  TCB  foundation  for 
TRUDATA  TFE  functions,  and  the 
Intuitively  appealing  capability 
for  physical  as  well  as  logical 
encapsulation  of  the  DBMS, 


6)  Major  TRUDATA  project  milestones 
( t 7 ] ,  [8] ,  [221 )  have  been 

produced,  reviewed,  and  presented 
to  industry  and  Government  from 
the  very  outset.  These  papers 
describe  not  only  the  "product" 
but  also  the  continuing  "process" 
used  to  take  the  next  development 
steps . 


Invoke  the  "social  process"  right 
from  the  start.  Inform  and 
involve  the  cognizant  Government 
agencies  and  technical  partners 
at  every  step.  Document  both  the 
milestones  (e.g..  system 

architecture,  security  policy) 
and  the  process  used  to  reach 
those  milestones. 


THE  ROAD  SO  FAR 


We've  followed  our  own  six  "traveling 
tips"  as  we've  moved  down  the  road  to 
TRUDATA  implementation.  For  example: 

1 )  Market  surveys  and  our  own  secure 

systems  development  experience 
provided  implementation 

characteristics  (e.g., 

functionality,  performance,  size, 
cost)  for-  TRUDATA  from  the  very 
beginning. 

2)  We  adopted  the  Naval  Surveillance 

System  (NSS)  operational  model 

described  in  II]  and  broadened 

in  [ d ]  as  our  mission  archetype. 

3)  We  have  invoked  a  process  of 

constant  self-examination  to  make 
sure  that  our  security  policy 
supports  the  mission  archetype 

and  abides  by  reasonable 

interpretations  of  (6J  as 

amplified  by  tne  most  recent 

successful  research  results. 


Progress  along  the  road  to  a  TRUDATA 
Implementation  has  occurn  1  in  short 
bursts  of  "breakthrough"  speed 

interspersed  with  periods  of  "idling  in 
Place".  The  major  milestones  of 

architecture  specification  [7J,  security 
policy  description  13),  and 

implementation  planning  [22J  have  each 
with  a  period  of  technical 
and  review,  market 

and  project  consolidation 
march  forward  to  the  next  milestone, 
we  proceed  through  our  implementation 


been  followed 
ref 1 ec  t ion 
reaf  f  irmat.  ion. 
to 
As 


plan,  we  anticipate  a  continuation  of  the 
"speed  up-then-elow  down"  (and  maybe  even 
backup!)  cycle  as  we  attempt  to  navigate 
the  specifics  of  an  implementation 
without  the  benefit  of  an  "official 
roadmap",  l.e..  Trusted  DBMS  Evaluation 
Criteria,  Summaries  of  each  of  the  major 
milestones  leading  up  to  actual 
implementation  are  provided  in  this 
survey  of  our  Journey  to  date.  Full 
descriptions  mty  be  found  in  the 
references . 


TRUDATA  ARCHITECTURE  SUMMARY 

TRUDATA  combines  the  classical 
"Integrity  Lock"  and  "Kernelized" 
architectures  from  the  Summer  Study  with 
an  additional  "Trusted  Filtering"  notion 
described  in  [9)  to  form  the  basis  for 
the  TRUDATA  System  Architecture  17]  os 
shown  in  Figure  1.  Two  main 
architectural  components  provide  the 
necessary  functionality: 


11)  We've  constrained  ourselves  to 
generally  accepted  (though  not 
yet  officially  sanctioned) 

trusted  DBMS,  techniques  and 
practices  in  design  and 

development  while  still  allowing 
ourselves  the  necessary  freedom 
to  Innovate  wherever  creative, 
compromises  must  be  made. 

5)  From  among  a  number  of 
architecturally  possible 

candidates,  we  have  chosen  AT&T's 
System  V/MLS  secure  UNIX  as  the 
basis  fox'  the  Initial  TRUDATA  TFE 
and  the  Britton  Lee  1DM  as  the 
Initial  TRUDATA  DBMS  component. 
Crucial  to  these  choices  was  an 


1)  The  TRUDATA  architecture 

concentrates  all  "trust"  for  data 
and  process  security  in  a  Trusted 
Front  End  (TFE)  component . 

2)  The  DBMS _ component _ (DBM?  is 

completely  encapsulated.  making 

the  only  avenue  of  access  to  data 
management  services  through  the 
TFE. 

While  we  allow  the  DBM  component  to 
maintain  data  integrity  and  perform 
typical  DBMS  services  (e.g.,  query 
resolution,  data  update),  we  do  not  trust 
it  to  do  so  in  accordance  with  the 
TRUDATA  secui'ity  policy.  The  integrity 
locking  technique,  performed  entirely  in 
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a  priori.  no  sy;»tom-  driven 

cla3sl  f  teat  ion  attempts  need  be 
made.  By  making  mviews 

"read-only",  difficult  update 
classification  decisions  can  be 
avoided  without  sacrificing  the 
real  utility  of  data  fusion  in  h 
database  application. 

3)  A  clearance  vector  for  users 
( subjects )  which  can  be  used  to 
enforce  data  classification 

control  without  constraining 

operational  personnel  to  an 

unworkable  disjointed  scenario  of 
partial  data  construction  and 
review . 


TUB DATA 
ARCHITECTURE 


Vii'iirc  1 


the  TFE,  imparts  tha 
by  "checking  up"  on 
accuracy  of  all  data 
the  TFE.  A  trusted 
TFE,  either  olimi 
non-secure  DBM  funct 
they  are  sent  to  th 
them  for  equivaln 
requests  (  "comntut 

Finally,  additiona 

interface  software 
for  the  secure 
operation  of  TRUDATA. 
interface  is  SQL. 


t  "trust"  to  the  DbM 
the  integrity  and 
entering  and  leaving 
filter,  also  in  the 
nates  fundamentally 
ion  requests  bef ore 
e  DBM  or  exchanges 
nt  necure  function 
fltive  filtering")  . 
1  trusted  user 

in  the  TFE  provides 
administration  and 
The  TRUDATA  system 


TPiinJTfl  SECURITY  POLICY  SUMMARY 


Entitles.  The  TRUDATA  security  model 
consists  of  five  types  of  entitles: 


The  TRUDATA  Security  Policy  Model  18] 
la  a  derivative  of  the  Naval  Surveillance 
System  (NSS)  Security  Model  described  t>y 
Graubart  and  Woodward  in  111.  While  we 
have  adopted  many  of  the  same  definitions 
and  subpolicies  espoused  In  the  NSS 
model.  the  TRUDATA  policy  Is 
distinguished  by  several  new  end 
different  concepts,  each  of  which  helps 
to  maintain  a  theoretically  consistent 
model  while  at  the  same  time  supporting  a 
practical  concept  of  operations.  Amons 
the  more  important  features  of  the  model 
are ; 


Adjustable  view  jfcve. 
By  making  data  acce 
only  through  pre-def 
TRUDATA  permits  the 
Administrator  ^DBA) 
variations  of  security 
granularity  extending 
level  security  (where 
defined  view  is  th 
entire  record)  tc 
security  (in  which  s 
views  are  defined). 


1  security . 
ss  possible 
lned  views. 
Data  Base 
to  supply 
protection 
from  record 
tin  the  only 
tat  for  the 
field  level 
i  ingle  field 


2)  The  introduction  of  special ly 

constrained _ view  types  called 

"pviewe"  and  'Views"  as  vehicles 
to  control  the  irferencing  and 
aggregation  problem  botn  within 
and  across  records.  By  forcing 
all  views  to  be  defined  and 
assigned  a  default  security  level 


1)  subjects 

2 )  obj  ec  to 

3)  security  levels 

t'  )  operators 

5)  security  policies 

Sub J  ec t  a .  The  subjects  in  this  mcdel  are 
the  users.  Each  user  is  assigned  a 
clearance  vector  <d.u>  which  establishes 
clearance  level  boundaries.  The  u 

component  is  the  maximum  clearance  level 
of  the  user  and  the  d  component  is  the 
min  1  mum  clearance  level  of  the  user. 
Each  user  of  the  system  is  also  assigned 
an  access  1 evel  <a>.  This  level  is  the 
current  security  level  of  the  user  and 
must  always  satisfy 

d  <  =  a  <=  u 

Operator  Authorization  List.  In  addition 
to  clearance  levels,  there  is  also  an 

erator _ au t  horlzat ion  list  ( O  A  L ) 

associated  with  each  user.  Only 

operators  on  this  list  can  be  invoked  by 


?0  4 


Likewi  ae 


an  mview  could  be  defined  ^3: 


trie  user.  Consequently.  OAL’c  are  used 
to  help  define  the  role  within  which  each 
typo  of  user  must  behave. 

Objects.  The  objects  in  this  model  are: 

1 )  data  bases 

2)  relations 


3)  create  n»v lew  diagnosis 

as  select  ptag  from 

pat  louts , 

xr ay  from  labwork 

where 

patlant^mim  -  pat  lent _num 


3)  records  (also  called  tuples) 
i\  )  views 

5)  fields  (also  called  atti'ioutes) 

Databases  contain  relations.  which 
contain  records,  whose  contents  (i.e.. 
field  values)  are  available  onl y  through 
views . 

views.  Views  are  named  collections  of 
fields  within  one  or  more  relations. 
There  are  two  kinds  of  views.  Prlmi t lve 
v 1 ews ,  called  pv lews .  consist  only  of 
fields  from  a  single  relation.  i.e.. 
pviews  are  a  projection  from  within  a 
relation.  Mul t 1 views .  called  mvlews . 
consist  of  a  join  of  pviews  within  a 
database.  To  illustrate.  consider  two 
relations  in  a  HOSPITAL  database,  one  for 
PATIENTS  and  one  for  LABWORK.  These 
relations  are  shown  pictorially  in 
Figure  2. 
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in  content 
however,  one 
significant  distinction.  Namely,  the 

baseviow  can  behave  as  a  container  within 
a  relation,  providing  a  vehicle  to 
control  the  view  aggregation  problem  in 
much  the  same  way  as  relation  containers 
control  the  record  (basevlow)  aggregation 
problem  and  database  containers  control 
the  relation  aggregation  problem. 

Protection  Granularity.  With  our 

definition  of  views,  we  can  now  catalogue 
TRUDATA  objects  as  either  containers  or 
atoms.  TRUDATA  containers  are  databases, 
relations,  and  basevi ews/records .  Views 
(including  baaeviews)  are  TRUDATA  atoms 
because  they  are  the  smallest  unit  of 
information  in  the  system  to  which 


PATIENT  Relation 


Las t name 

!  Firstname 

!  Patien 

t._Num  ! 

-  *  *  1 

LABWORK 

Relation 

Lab_Date  ! 

Patient_Num  ! 

Filmid 

Technician 

;  . . . ! 

Figure  2 


From  the  relations 
would  be  defined  as: 


in  Figure  2  pviews 


1  ) 


2) 


create  pview  pt ag 
as  select  Ustnottie, 
f i rs t name , 
pa t ien t_num 
from  patients 

create  pview  xray 

as  select  filrnid, 

technician. 

pat ien t„num, 

lab_date 

from  labwork 


explicit  classifications  are  attached. 
Two  interesting  and  helpful  results  occur 
naturally  under  this  definition: 


1  ) 


Dae  e views 


behave 


as 


both 


containers  and  atoms,  depending 
on  their  usa/purpose  within  an 
application-  Whenever  whole 
records  (with  their  field 
values)  are  legitimately 
accessed  via  the  baseview.  the 
baseview  operates  aa  an  atom  by 
providing  an  explicitly  labeled 
collection  of  data.  Likewise, 
whenever  subcollections  of  data 
within  a  record  are 
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legitimately  accessed  via  other 
views .  the  baseview  operates  as 
a  container  by  providing  the 
0 uper imposed  mandatory  access 
control  sal-vice  (the  container 
clearance  requirement )  in  the 
same  way  that  database  and 
relation  containers  perform. 


Securl ty 

l.abe  1  a  . 
of  both 
set  (pos 
categorlo 
objects 
relat ions 

rOr  oub 

clearance 
access  o 
classlf lc 
coord i nat 
vector  co 


At  oml c 


level 


protect  ion 


granularity  is  configurable  by 
the  DBA  a) 1  the  way  from 
"record  level"  security  (with 
only  a  basevlew  defined)  to 
"field  level"  security  (with 
single  field  pviews  defined). 
Note  that  fields  are  in  some 
sense  "sub-atomic"  units  of 
information  because  they  are 
only  accessible  through  a 
view.  Note  further  that  field 
and  view  level  security 
collapse  into  the  same  thing 
(an  "atomic  fusion"  of  sorts) 
whenever  single  field  views  are 
defined . 


Levels . 


TRUDATA  security  labels  consist 
a  hierarchical  component  and  a 
sibly  empty)  of  non- hi erarch 1  cal 
s.  Subjects  and  data  access 
(i.e.,  views,  baseviews/records . 

,  and  databases)  are  labeled. 
Jecls,  labels  represent  tne 
a  held  by  the  subject.  For  data 
bjects.  labels  represent  the 
ation  of  the  object.  Each 
e  of  the  subject  clearance 
nolsts  of  a  TRUDATA  label. 


All  data  access  objects  are  labeled 
with  on  actual  security  level  1ASL) .  A 
default  ASL  must  be  provided  when  data 
access  objects  are  defined. 
Subsequently.  the  ASL  is  cither 
explicitly  provided  when  an  instance  of  a 
data  object  is  created  (e.g.,  a  record  is 
created)  or  the  defined  default  ASL 
becomes  the  ASL  for  the  instance.  i.e.  . 
the  defined  default  ASL  Is  inherited  by 
the  actual  instance  of  the  data  access 
object . 


Except  for  pviews.  the  default  ASL 
of  a  data  access  object  can  be  less  than, 
greater  than.  or  equal  to  that  of  its 
container.  The  ASL  of  a  pvlew  must 
always  be  less  than  or  equal  to  that  of 
its  basevlew  container  (since.  in  fact, 
such  a  restricted  view  always  provides 
leas  data  access  than  that  of  its 
basevlew  container).  Such  a  restriction 
eliminates  possible  conflicts  between 
data  access  to  a  basevlew  and  to  some 
pvlew  within  that  basevlew  container. 


the 

subject 

satisfies 

the 

onary  access 

policies 

as 

the 

CCR  label. 

Thus,  the 

CCR 

each  container  is  labeled  with  a 

Container  Clearance  Requirement  ( CCR ) 

label  and  access  to  any  data  within  a 
container  is  only  allowed  if  the  acce  -i 
level  of 
nor.-di  sore 
applied  t 

represents  a  "minimum"  clearance  level  t 
be  satisfied  before  access  to  any  data  1 

the  con*ainor  is  allowed.  For  example, 
the  CCR  can  be  used  on  a  basevlew  to 
Insist  that  users 'have  a  Secret  clearance 
before  seeing  any  data  via  otherwise 
authorized  pview(s),  even  though  all 
pviews  may  only  be  labeled  as 

Confidential.  Such  a  capability  supports 
control  over  "horizontal  aggregation" 
(multiple  views  within  a  record;  as  well 
as  "vertical  aggregation"  (a  single  view 
across  many  records). 


The  CCR  label  has  no  relationship 
with  the  default  ASL  of  a  container.  The 
CCR  may  be  less  than,  greater  than,  or 
equal  to  the  default  ASL.  Furthermore. 
In  recognition  of  the  exceptionally 
strong  tie  between  the  definition  of  the 
relation  and  the  automatlcal.il'  associated 
basevlew  container,  the  CCR  of  the 
relation  is  also  defined  to  be  the  CCR  of 
the  basevlew. 
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access 
to  each 
the  list 
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function.  I.e..  F.XL 's  list  all  subjects 
for  whom  specific  access  outhorl zet i ons 
are  denied . 


Container  Protection.  The  TRUDATA  model 

enforces  a  container _ c  tearance 

requ 1  remen t  (CCR)  for  all  data  access. 
[Note:  This  is  a  uniform  application  of 
the  Container  Clearance  Required  notion 
from  Landwehr's  MMS  model  described 
in  [17].]  In  addition  to  a  default  ASL, 


Oper a t ors ■  Users  act  upc  i  data  with 
operators.  There  arc  three  classes  of 
operators  in  the  TRUDATA  security  model: 

1)  Those  that  access  data. 

2)  Those  that  define  data. 
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3)  Those  that  manipulate  the 
mandatory  and  discretionary 
access  attributes  of  data. 

Subjects  can  only  use  those  operator? 
that  are  listed  in  their  OAL.  The  rsnga 
of  applicabilty  of  each  class  of  operator 
is  shown  in  Figure  3. 


Discretionary  Access  Control 

Discretionary  access  control  is 
enforced  usings  ACLs  and  EXLe. 
The  ACL/EXL  of  the  object,  as 
well  as  the  ACL/EXL  of  the 
object's  contalner(B)  if 
necessary,  must  authorize  (and 
not  exclude)  the  subject's 
requested  operator  access  to 
t he  object . 


The  security  policies  define  the 
relationships  anong  users,  operators,  and 
objects.  Consequently,  the  policies  are 
described  in  [8]  as  they  apply  to  each 
class  of  operator,  l.o.,  data  access, 
data  definition,  and  att  lbute  changing. 


Operator  Classes  and  Applicability 


Operator 

Class 


Operator 

Name 


Operator 

Applicability 


Data 

Access 


Read 

Write 

Del ete 


All  data  access  objects 
All  data  access  objects 
except  mviews 
Containers  only 


Dii.  t  £. 

Definition 


Dof 1 na-dh 
Def ine-rel 
Define- view 


Databases  cnly 
Relatione  only 
Relations  only 


Attribute 

Changing 


Change- 1 eve 1/Read 


Change-access 


All  data  access  objects 

except  mvlews 

All  data  access  objects 


Figure  3 


Policies .  Subject  to  object  access  is 
controlled  under*  a  combination  of  three 
sub-policies.  The  requirements  of  al 1 
three  eub-pollcieB  must  be  met  before  any 
specific  access  operation  is  allowed. 

1 )  Operator  Authorization. 


Subjects  access  objects  with 
operators.  A  subject  can 
invoke  an  operator  only  If  that 
operator  is  on  the  subject's 
OAL. 

Mandatory  Access  Control 

Mandatory  ( non - d i sere t ionary ) 
access  control  involves  the 
subject's  security  level.  the 
ASL  of  the  object,  and  the  OCR 
of  the  object's  con t ainer ( s ) . 
The  subject's  security  level 
must  be  sufficient  to  satisfy 
the  mandatory  access  policies 
applied  to  the  object  for  the 
given  operator. 


Added  DBA  Responsibilities.  The  TRUDATA 
security  policy  adds  respons i bi 1 t ies  to 
the  role  of  the  DB\  and  the  system 
operator,  primarily  to  inspect  and 
maintain  data  integrity. 

A  Word  About  Integrity  and  Inference 

Conflict  Between  Secrecy  and  Integrity. 
Much  recent  research  [8,18,19,20)  has  led 
time  and  again  to  the  frustrating 
realization  that.  an  inherent  conflict 
exists  between  data  secrecy  and  dato 
integrity  in  database  management 
systems.  Data  secrecy  policies  and  data 
integrity  policies  are  fundamentally 
orthogonal  in  motivation  and  practice. 
Inclusion  of  broad  integrity  subpolicies 
inevitably  loads  to  a  spiral  of 
unacceptable  covert  and  inference 
channel s . 


Current  TRUDATA  Approach.  We.  too,  have 
confronted  this  situation  In  our  effort 
to  move  generally  accepted  notions  of 
trusted  DBMS  service  from  theory  to 
reality  with  the  application  of  careful 
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encinocrine  Judgment  to  a  sound  system 
architecture  against  a  bficKdi'op  of  real 
operational  needs.  We  are*'  concerned  with 
data  integrity  issues  &.c  well  as  data 
security  issues.  The  selection  of  a 
proven  DBMS  component  with  an  extensive 
history  of  performance  and  an  impressive 
capability  for  preserving  data 
consistency  reassures  us  that  TRUDATA 
will  be  able  to  maintain  database 
service*  The  available  consistency  tools 

and  mechanisms  for  recovery  bode  well  for 
TRUDATA  as  a  reliable  as  well  as  trusted 
DBMS.  In  addition,  the  healthy  sot  of 
access  controls  included  in  the  TRUDATA 
security  policies  represents  a  strong 
contemporary  approach  to  controlling 
inference . 

Basis  for  Implementation  Decisions.  Yet. 
like  (l8),  we  continue  to  base  our 
implementation  decisions  on  the  premise 
that  "the  security  policy  has  precedence 
over.  and  a  prior  existence  to,  the 
integrity  policy**.  Therefore,  wherever 
the  introduction  of  "supporting**  policies 
such  as  integrity  policies  would  reduce 
the  ability  of  TRUDATA  to  enforce  its 
security  policy,  we  have  ruled  in  favor 
of  security  policy  enforcement  as  long  as 
the  operational  problem  archetype  does 
not  suffer.  We  expect  that  we  will 
ultimately  be  able  to  reconcile 
additional  integrity  policies  (e.t.. 
constraints,  rules)  to  ouj.  security 
policies.  Through  our  owr,  discoveries, 
as  well  si  other  ongoing  research  such  as 
that  reported  in  [20),  we  anticipate  that 
so me  reasonable,  implement Able  mechanisms 
will  be  identified.  We  have  allowed  for 
their  eventual  inclusion  beyond  our 
Phase  I  implementation  program- 
Initially,  however.  database  Integrity 
will  be  a  large  responsibility  of  the 
SD&a.  The  SDba  must  recognize  when 
integrity  considerations  (constraints) 
impact  data  organisation  and 
classification,  and  then  manifest  that 
recognition  with  tho  right  Container 
Clearance  Requirement  (CCR)  and  default 
Actual  Security  bevel  (ASL)  selections 
(so  that  there  is  no  newly  introduced 
inference  channel). 


Sufficiency  of  Cu 
with  [19)  that  it 
integrity  policy 
mandated  at  all. 
consensus  that 
of  [6]  3hould  no 
for  controlling  1 
believe  that  our  c 
satisfies  the  ne 
implementation  ult 
B2  level ,  whi 1© 
providing  for  supp 
new  practical  pose 


rrent  policy.  We  agree 
is  unclear  whether  any 
for  DBMR ' 0  must  be 
In  view  of  the  evolving 
a  DBMS  interpretation 
_t  include  requl remen  t  o 
nfet’ence  (ref  [21]).  wc- 
urrent  policy  direction 
eds  for  an  MLS  DBMS 
imately  targeted  at  the 
at  the  same  time 
orting  policy  growth  ©3 
ibilities  emerge. 


TRUDATA  IMPLEMENTATION  SUMMARY 


Initial  Configurer i on 


Based  on  our  TRUDATA  operational 
requirements  for  &  deployable, 
supportable  system.  an  already  trusted 


operating  system  foundation.  and  a 
readily  encapsulated  DL3MS  capability.  we 
have  chosen  to  configure  our  initial 
TRUDATA  system  with  an  AT&T  3H2  Model  *100 
running  system  V/MLS  aa  the  1 FL  component 
and  a  Britton  Lee  i DM  a 3  tho  DBMS 
component-  We  are  i  1 lowing  our  B2  level 
system  target  Implementation  Plan,  even 
though  the  current  version  of 
System  V/MLS  is  in  evaluation  for 
FU  level  certification-  Our  instant 
target  is  for  an  initial  MLS  TRUDATA  at 
the  b  1  level.  with  an  ultimate  version 
(using  even  more  secure  versions  of  our 
baseline  TFE  operating  system)  targeted 
for  D  2  .  Britton  Lee  databa.se  machines 
provide  the  added  reassurance  of  physical 
as  well  as  logical  encapsulation,  plus 
hio-n  performance.  a  relational  data 


ex i s  t lng 


high  performance, 
model.  and  an 
organization. 

Imp lemon  tat  Ion  Issues 


No  Official  Criteria.  The  absence  of  an 
"official”  set  of  security  criteria  for 
trusted  database  management  systems 
introduces  an  extra  element  of  ambiguity 
into  certain  implementation  choices. 
Much  effort  Is  currently  being  directed 
at  discovering  exactly  what  it  means  to 
ha  a  "secure  DBMS"  certifiable  to  any 
specific  level  of  trust.  We.  too.  are 
participating  in  that  effort  as  we 
prepare  a  TRUDATA  whirl)  balances 
mission-based  functional  and  performance 
imperatives  with  security  policies  that 
abide  by  generally  accepted  (If  not 
formally  sanctioned)  DBMS 
interpretations. 

Makl  r.g  and  Tracking  1  mpl ement a t _ion 
Choices.  The  National  Computer  Security 
Center  (NCSC)  is  currently  attempting  to 
coalesce  a  sot  of  criteria  for  trusted 
DBMSs .  However,  even  If  such  a  set  of 
criteria  were  extant,  the  nature  cf  a 
secure  syBtom  implementation  would  3till 
leave  some  of  the  thornier  im;  l  anion  t  at  ion 

choices  unresol vable  without  experimental 
data  and/or  extensive  collaborative 
deliberation.  Certain  semantic  choices 
and  covert  channel  bandwidth  control 
choices  are  especially  appropriate  to 
tills  category. 

In  response  to  this  situation,  we 
have  chosen  to  Institute  a  "living' 
document.  our  TRUDATA  Implementation 
Issu :s  (TISSUES)  List ,  around  which  we 
focus  .specific  decision  making  efforts  as 
we  attempt  to  resolve  (and  document ) 
every  Judgment  issue  discovered  during 
implementation.  We  expect  the  TISSUES 
List  to  grow  and  shrink  over  time  as 
Implementation  choices  are  made.  Our 
first  version  of  the  TISSUES  1.1st  had 
1U  different  TISSUES  to  resolve- 


Imp  lent e  ntatlon  Sc  licdu  1  e 

TRUDATA  implementation  is  proceeding 
according  to  the  TRUDATA  implementation 
Rian  The  first  phase  of  implementation 
Is  scheduled  to  occur  In  two  stages. 


Stage  1  la  scheduled  to  end  In  the  winter 
of  1987  with  a  prototype.  Stage  2 

finishes  with  our  initial  111  target 
version  In  mid  1988.  subsequent  phases 
are  anticipated  to  move  to  a  82  targeted 
level  and  to  Install  more  user  support 
tools,  on-line  expert  Secure  Data  Base 
Administration  (SDI)A)  guidance,  and  more 
refined  supporting  policies. 

Implementation  Procedure 

TRUPATA  is  being  implemented  In  a 
"closed  security  environment"  according 
to  National  Computer  Security  Center 
guidance  in  » 1 6 J .  After  establishing  the 
TRUDATA  development  facility  and  TRUPATA 
Configuration  Management  Plat.  and 

procedures.  implementation  is  proceeding 
according  to  the  following  pattern: 

1)  "Absorb”  the  Britton  bee  Portable 

Host  Interface  (PHI)  source  code 
and  place  under  TRUDATA  CM. 
"Absorption"  Includes  a 

llne-by-line  inspection  of  all 
existing  code  to  check  for  Trojan 
Horses  and  trapdoors. 

2)  Activation  of  the  TRUPATA 

Assurance  Program  (.TAT) 

consisting  initially  of  rigorous 

configuration  management.  a 

continuous  teat  program.  and 

formal  model  interpretation.  The 
TAP  will  be  supplemented  with 
covert  channel  analysis  after 
Stage  1  is  complete. 

3)  Confirmation  of  the  standard 

Britton  Lee  UNIX  PHI  software  in 
the  System  V/MLS  version. 

а)  Insertion  of  the  new  "trusted 
authenticator"  software  at  the 
system  interface  level  of  the  PHI 
software.  Careful  examination  of 
references  l 10]  through  115]  and 
analysis  of  PHI  architecture  as 
documented  in  122]  ha3  isolated 
the  points  of  protection  to  Just 
a  handful  of  routines  (which  must 
now  be  trusted). 

5)  Addition  of  Trusted  User  Services 
and  Trusted  Filter  software. 

б)  Completion  of  data  delivery 
services  software. 

7)  Completion  of  Security  Features 
User’s  Guide  and  Trusted  Facility 
Manual . 

Stage  1  is  complete  after  step  4. 
The  remaining  steps  complete  Stage  2. 
Superimposed  over  the  entire  pattern  is: 

1)  A  program  of  perl  1c  reporting 
and  review  with  development 
partners  and  involved  Government 

agencies . 


2)  The  maintenance  of  a  "living" 
document  (the  TISSUES  List)  which 
tracks  1 mpl oment av ion  issues  and 
their  resolution  throughout  the 
ltnplemen t at  i on  process. 

3)  Concurrent  development  of  on 

application  scenario  as  a  way  of 
confirming  our  Imp  1 omen 1  at  ion 

decisions  and  demonstrating 

trusted  DBMS  services. 
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THE  SYBASE  SECURE  DATASKRVER: 

A  SOLUTION  TO  THE  MULTILEVEL  SECURE  DBMS  PROBLEM 


Patricia  A.  Rougcan 
Edward  1).  Slut  tits 

T  RW  Federal  Systems  Gioup 
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INTRODUCTION 

Today’s  database  management  system  (OHMS)  technology  is 
severely  limited  in  its  ability  to  protect  sensitive  mtoimatiori  and 
meet  the  increasingly  demanding  performance  requirements  of 
many  government,  military,  and  private  sector  data  ptocessing 
systems.  Current  high  performance  DBMSs  do  not  offer  data 
security,  and  previous  secure  DBMS  prototypes  suffcied  in  their 
pci  formative,  flexibility,  and  maintainability.  The  Sybase 
Secure  DataSetver  (SYSDS)  effort  intends  to  solve  both  the 
security  and  performance  problems  associated  with  modem, 
relational  DBMSs. 

This  paper  presents  the  SYSDS  approach  to  solving  the  secure 
DBMS  problem.  The  SYSDS  is  a  multilevel  secure  relational 
DBMS,  based  on  the  Sybase  relational  DBMS  known  as  the 
PataServer*.  The  SYSDS  is  currently  under  development.  The 
original  SYSDS  approach  took  advantage  of  the  fact  that  the 
PataServet  was  in  an  early  development  stage.  The  current 
PataServer  represents  a  state-of-the-art  relational  data  manage¬ 
ment  system  which  when  modified,  yields  n  cost-effective, 
reliable  multilevel  secure  DBMS  that  does  not  sacrifice  essential 
performance  characteristics. 

THE  TRUSTED  DBMS  PROBLEM 

In  D82,  the  Air  l'oree  Studies  Board  stated  that  computer  security 
technology  had  advanced  to  the  point  where  certifiable  multilevel 
secure  DBMSs  could  be  built  in  the  neat  term  [AESB83].  However, 
this  technology  has  not  ntatei  iali/.ed  in  the  commercial  marketplace. 

The  SYSDS  addresses  several  problems  confronted  by  designers  of 
multilevel  secure  database  management  systems.  These  include: 

•  Storage  of  multilevel  data 

•  Data  and  system  integrity 

•  Performance 

•  Design  Criteria 

•  Technological  Obsolescence. 

Storage  of  Multilevel  Data 

Most  commercial  operating  systems  that  attempt  to  provide 
mandatory  and  discretionary  security  controls  do  so  at  the  file 
level.  This  is  insufficient  for  many  applications,  particularly  in  a 


•DataSeivct  is  a  tiadcm.uk  of  Sybase,  Inc. 


military  command  and  control  environment  where  the 
granularity  of  access  protection  must  be  very  fine.  The  SYSDS 
design  provides  mandatory  protection  at  the  row  level,  with  up 
to  16  hierarchical  classifications  and  64  non-hictarchiul 
categories. 


Data  and  System  Integrity 

The  DoD  Trusted  Computer  System  I'wlituiion  Criteria  (the 
Criteria),  the  governing  document  behind  computer  scent uv. 
docs  not  address  the  problem  of  data  integrity,  a  problem  partic¬ 
ularly  applicable  to  database  management  systems  [DOD  T83], 
The  SYSDS  approach  addresses  this  problem  in  three  ways. 
First,  protection  against  inadvertent  ertots,  such  as  hardware 
problems,  is  provided  by  the  use  of  an  integrity  field  covering 
every  data  page.  This  integrity  field  contains  an  error  detection 
code  called  a  cyclic  redundancy  check  (CRC).  The  ORC  is  used 
fi'i  integrity  purposes,  not  for  security  purposes,  since  the 
SYSDS  is  a  reference  monitor  approach.  Second,  t he  SYSDS 
interfaces  with  ncf.vork  encryption  devices  on  output  for  secure 
cud-to-end  transmission  of  data  over  untrusted  net  wot  ks.  These 
two  methods  provide  data  integrity  both  within  the  SYSDS  and 
between  cooperating  hosts.  Third,  the  SYSDS  introduces  the 
concept  of  Tt usted  Computing  Base  (TCB)  integrity  by 
separating  ti  listed  code  into  two  hardware  supported  execution 
domains  to  help  limit  the  amount  of  trust  aifouied  to  each 
domain.  This  unique  approach  provides  system  integrity. 

The  SYSDS  offers  other  DBMS  intcgiity  features  not  included 
in  the  TCB.  For  example,  the  SYSDS  enforces  range  cheeks  and 
triggers,  but  these  mechanisms  arc  not  enforced  \ia  trusted 
code.  They  wete  intentionally  left  out  of  trusted  code  to  help 
reduce  the  si/e  of  the  TCB.  Placing  them  in  trusted  code  would 
have  meant  including  a  substantial  portion  of  the  SQI  Compile! 
in  the  TCB,  making  the  TCB  significantly  larger.  In  essence,  this 
corrupts  the  purpose  of  a  reference  monitor  approach  since  the 
reference  monitor  would  no  longer  be  small  enough  to  verily. 

Performance 

One  of  the  largest  problems  in  the  construction  of  secure 
systems  is  that,  whether  the  system  is  an  operating  system  or  a 
secure  DBMS,  security  controls  often  degrade  system  petfor- 
rnanee  to  the  point  that  the  system  no  longet  meets  operational 
requirements.  This  renders  the  system  secure  but  impractical  for 
the  mission  or  application.  The  result  is  that  security  controls 
arc  turned  off  or  compromises  arc  made  and  organizations  aic 
forced  to  purchase  iinsceuie  systems  that  better  nice:  the  pci  lot- 
rnanee  requirements  of  the  application.  System  users  will 
tolerate  some  performance  degradation  due  to  security,  hut  it 
must  he  minimal. 


The  SYSDS,  ;is  noted,  is  based  on  an  cmucTy  tc  aiiTnlcetcd 
DataSet  vet.  I  his  approach  is  unique  in  dial  die  DaiaSeivei  was 
designed  with  pet  lot  mance  in  mind,  yielding  an  advanlage  in 
modifying  die  system  to  meet  (.'lass  112  iccpmciucnts  as  spuilicd 
in  the  Oiteiia.  1  he  SYSDS  was  designed  without  intiodneing 
excessive  ii.sk  and  peiloinianee  penalties.  At  the  nine  ol  the 
original  SYSDS  design,  the  DataSetvet  itsell  was  in  tin  eatly 
development  stage  making  it  is  amendable  to  the  type  o!  v  hange 
needed  lot  seemily  •  changes  that  have  pi  oven  vet)  diliieiilt  to 
implement  in  existing  eommeieial  DttMS  piodnets. 

The  SYSDS  design  takes  lull  advantage  ol  high  peiloinianee 
feat  lire's  found  in  the  Sybase  DataSetsei.  A  ptimaiy  goal  ol  the 
SYSDS  vfloit  was  to  modily  the  DataSeivct  desip.n,  adding 
seemily  tneehanisnis  while  piesemng  the  leauiies  which  piovnle 
high  peiloinianee  To  help  meet  this  goal,  the  SYSDS  wtll  uni 
on  a  hate  maehine,  making  it  a  seeute,  high  peiloinianee 
database  maehine. 


Design  C  riteria 

1  he  Do/)  Iritslcti  ( (US,"  titer  System*  Ivulnetion  ( 'menu  is  the 
guiding  doenment  governing  the  design  and  developmeiu  ol 
seettre  systems.  Dnlottunalely,  this  doenment  was  originally  in 
tended  to  setve  the  neeils  ol  updating  system  designets,  and  in 
some  ease:.,  eannol  readily  he  extended  to  govern  the  eonxiitic- 
tiott  of  database  management  systems  lei  eotteet  tins  situation, 
tile  National  C'ompntei  Seeuiity  C'enlet  is  developing  a  set  ol 
Ti listed  DllMS  (inidelines.  In  the  absence  of  1  rusted  DBMS 
(iuidelines,  the  C'litcri;-.  inusi  be  applied. 

According  to  the  C  riteria,  applications  which  use  labeled  data 
must  address  the  11  Division  requirements.  Specifically,  the 
SYSDS  intends  to  meet  the  Class  112  level  leipiiiemcius,  with  the 
addition  of  special  integrity  mechanism--. 

Current  thinking  in  the  secuiity  eonumnuly  indicates  that  a 
database  management  system  must  lie  evaluated  togctliei  with 
;he  operating  system  on  which  it  tesides.  The  SYSDS  approach 
alleviates  this  piobleni  —  there  an:  very  few  112-level  secure 
operating  systems  —  by  residing  oil  bate  hardware  without  the 
support  of  a  commercial  opeiating  system.  All  opeiatmg  system 
functions  are  part  of  the  DttMS  kernel. 


1  cehnologieat  Obsolescence 

Because  of  the  delays  jtiheieut  in  secure  system  development, 
many  secure  systems  fall  behind  the  state  of-ihe-ait  t>y  r lie  time 
tliey  reach  the  prototype  phase.  In  other  wotds,  they  are  ohso 
let e  shortly  aftei  proof  of  concept.  The  SYSDS  appioach  has  no 
definitive  answer  to  this  problem,  hut  a  growth-path  hits  been 
designed.  The  SYSDS  will  be  based  on  the  eommetei.d  Sybase 
DataServer,  allowing  enlianeeiiients  made  to  the  non  secure 
system  to  tie  applied  to  the  secure  vet  shin  on  a  ease  by  ease  basis. 
Ol  course,  the  SYSDS  will  have  to  he  te  certified  after  every 
major  update,  but  there  are  plans  lor  revisions  in  ordci  to  keep 
the  SYSDS  anient  with  the  staic-of  the  an  in  database  manage 
men!  systems. 

illf  SYSDS  SOl.D  I  ION 

Designets  of  dusted  DBMSs  have  difficulty  in  establishing  what 
software  need'.  Hi  he  trusted  and  what  can  remain  unlrusted.  In 
addition  to  the  mandatory  and  discretionary  policies  addressed 


in  the  (  iiicna,  seeute  database  designets  must  adchess  special 
inlcgnt)  issues,  including  domain  integnly  (e  g  iniigcol  values) 
and  tclalional  integiity  (c.g.  icTeicuti.il  mlcgitly).  Seeunty  con 
sicleiat ions  ate  liniliei  complicated  hy  the  wide  lange  ol  atcTu 
tec  tines  availat’le  to  the  DBMS  designet ,  I  tom  database  systems 
executing  on  lop  ol  a  t  at  get  opctaling  system  to  I  tick  end 
database  machines  using  no  eommeieial  operating  system  at  all 
(III  NNXfi) 

In  adcltessing  the  seemily  and  integiity  concerns  that  necessitate 
the  I  ('ll,  llictc  is  a  tendency  to  allow  the  I  C'll  pet  nuclei  logtow 
until  it  encompasses  the  maioitty  ol  the  DBMS  code.  II  tin,  hap 
pens,  the  DBMS  TCB  no  longci  satislies  the  teleience  tuoinloi 
eoneept  stated  in  the  (Y net  ta  since  it  w  ill  not  he  small  enough  to 
vcttly.  Schell  and  Denning  addicssccl  this  piohlun  by  delmiug 
two  K  B  petimeteis.  one  lot  m.uist.it cu v  seeunty  and  integiity, 
and  the  other  I  oi  diseieiionat  y  seeunty,  tcvoveiy,  etc. 
|  SC  T 1 1  Kf»J .  Tins  enabled  them  to  keep  the  mandatoiy  seem  tty 
keiiicl  small,  hut.  since  then  pitman  seemily  object  was  the 
data  view,  all  ol  the  semantic  iclaied  tools  in  the  DBMS  had  to 
teside  in  the  second  petiinelci.  1  his,  coupled  with  iceovcy  code 
and  othet  (lusted  tueehauisius,  could  potentially  make  the 
second  puimeict  large 

In  delimng  the  petimelei  ol  the  SY  SDS  I  ('ll,  the  following  con 
sidetatioits  weie  made.  Since  the  SYSDS  tuns  on  a  hate 
machine,  the  intetielations  and  dependencies  between  the 
DBMS  and  the  t.nget  opeiating  system  did  not  have  to  he  eon 
stde  ted.  Since  the  design  ot  the  comma c<ul  DataSet  ver  includes 
many  integiity  and  disci etioiuny  comiol  featuies,  a  decision  had 
to  tie  made  as  to  which  leatuic"-  to  keep  in  the  K'B  and  which 
lentiires  to  temovc  so  tiutl  the  ic  ii  woniii  not  he  too  iaige. 
Table  I  summat  i/es  DBMS  leauiies  inside  and  outside  the  1  C'B. 


Design  Feature 

SYSDS TCB 
Implemented 

Outside 

TCB 

i-ogin 

• 

Aut*  tog 

• 

Trusted  Recovery 

• 

M*vt*kxy  Acc*m  At  Record  Levs! 

• 

fttcix  SctfiteV  A ceni  At  Table  level  for  the 
Opo*  aborts  bdtcl.  Insert,  Delete,  Upgrade 

• 

Integrity  CRC  Chocks 

• 

Trusted  Operations 

• 

Range  Checfcr 

• 

Triggers 

9 

View  Protection 

9 

Deadlock  DotMJOn 

•* 

Uv  stock  Detection 

9 

Concunufry  Control 

9 

Table  1 .  Perimeter  of  the  T(T1 


One  option  eonsicleted  was  to  add  mandatoiy  security 
mecTiauisun  tc>  the  ot  igin.il  DataSet  vet  design  and  to  have  the 
entire  DBMS  become  the  TCB.  Using  veision  2.0  of  the  non 
seeute  Sybase  DataSet  vet  as  the  basis  ol  estimate,  with  39, 000 
line,  of  code,  litis  option  was  within  the  feasible  vet ifieation 
range.  SC'OMP,  certified  as  an  AI  system,  has  approximately 
35,000  lilies  of  code,  ahoui  10, (XX)  lines  of  Pascal  code  in  the 
security  kernel  and  another  25, (XX)  lines  ot  ('  code  in  the  trusted 
software.  Although  it  would  have  been  easier  to  designate  the 
entile  DBMS  (lusted,  ibis  approach  was  ; ejected  because  it 
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meant  that  the  TCB  would  contain  considerable  code  not  rele¬ 
vant  to  security  and  would  be  laigcr  than  necessary. 

A  second  option,  separating  mandatory  and  discretionary 
security  into  two  perimeters,  was  also  rejected.  Although  the 
mandatory  and  discretionary  mechanisms  could  he  separated, 
retaining  views  as  objects  would  have  made  the  two  domains,  in¬ 
cluding  hoth  mandatory  and  discretionary  controls,  almost  the 
same  size  as  the  first  option  —  nearly  the  whole  DBMS. 

The  approach  chosen  for  the  SYSDS  was  to  define  only  one 
TCB  perimeter  to  include  mandatory  security,  discretionary 
security,  integrity,  recovery,  auditing,  and  trusted  operations. 
Most  of  the  complex  semantic-related  code  in  the  SQL  compiler, 
was  placed  outside  of  the  TCB.  With  this  approach,  the  integrity 
features,  such  as  triggers,  arc  not  included  in  the  TCB.  Instead, 
these  features  are  available  outside  t he  TCB  and  can  be  used  to 
augment  or  enhance  the  SYSDS  security  policy.  The  secure 
operation  of  the  SYSDS  doe.;  not  depend  on  the  correct  use  of 
these  mechanisms.  In  this  way,  a  single  TCB  embodies  the  essen¬ 
tial  features  of  the  security  approach,  while  remaining  as  small 
as  technically  possible. 


THE  SYSDS  SECURITY  MODEL 


Subjects 

In  (lie  SYSDS,  subjects  are  active  entities.  A  subject  is  defined  as 
a  process  i tinning  on  behalf  of  a  user.  A  key  aspect  of  the 
SYSDS  design  is  that  the  database  will  be  a  stand-alone, 
dedicated  back-end  processor  Trusted  software  in  the  DBMS 
will  create  a  user  process  in  the  machine  for  the  duration  of  a 
usu  session.  The  user  process  is  assigned  the  security  level  of  the 
user  at  the  time  the  process  is  created.  Users  arc  allowed  to 
designate  the  security  levci  of  a  session  as  long  as  the  level  does 
not  exceed  the  maximum  clearance  of  the  user.  The  maximum 
clearance  of  the  user  is  stored  in  the  DBMS. 


Objects 

One  of  the  major  difficulties  associated  wi'h  applying  the 
Criteria  to  database  systems  has  been  effectively  defining  the 
varying  granularity  of  system  objects.  In  the  SYSDS  model,  an 
object  is  defined  as  one  of  two  types  of  objects: 

•  Primary  Object  (PO) 

*  Secondary  Object  (SO). 

A  PO  is  defined  as  a  data  row  (i.e.,  record  or  tuple)  in  a  table. 
All  POs  are  governed  by  the  mandatory  access  policy  and  the 
CKC'  integity  control  mechanism  but  not  discretionary  access 
policy.  SOs  are  defined  as  databases  and  tables.  All  SOs  arc  sub¬ 
ject  to  discretionary  access  policy  truly;  no  mandatory  access  or 
integrity  policy  is  directly  applied  to  SOs. 

The  definition  of  PO  and  SO  holds  for  all  SYSDS  objects, 
including  system  objects  in  t he  data  dictionary.  Since  every  row 
in  the  data  dictionary  is  considered  a  PO,  the  SYSDS  model 
adds  the  benefit  of  implementing  a  minimum  security  level  on 
accesses  to  databases,  tables,  or  even  columns,  regardless  of  the 
information  contained  in  them,  l  or  example,  a  database  may  be 
designed  to  contain  rows  vatylug  in  classification  from 


UNCLASSIFIED  to  TOP  SECRET.  However,  if  the  row  in  the 
data  dielionaiy,  which  refers  to  the  name  of  a  database,  is 
classified  CONFIDENTIAL,  then  all  users  who  reference  that 
datahase  must  have  a  login-level  of  at  least  CONFIDENT! AI.  in 
order  to  gain  access  to  that  database.  The  same  holds  true  for 
access  to  other  system  objects  such  as  tables  and  columns.  This 
SYSDS  design  feature  can  be  used  at  the  discretion  of  the 
datahase  designer.  If  this  feature  is  not  necessary  for  a  given 
application,  the  database  designer  can  create  all  system  objects 
at  a  system-low  or  UNCLASSIFIED  level,  meaning  t hat  eacli 
database  user  will  at  least  gain  access  to  the  system  object  names 
subject  to  discretionary  access  cheeks,  and  mandatory  access 
will  then  be  cheeked  at  the  row  level  of  the  base  tables. 

Defining  two  levels  of  system  objects  addresses  both  implemen¬ 
tation  efficiency  ami  Criteria  requirements.  First,  to  ensua' 
accurate  security  of  system  data,  mandatory  access  protection 
must  lit  applied  to  every  data  row  accessed  in  the  DBMS.  This 
prevents  a  disclosure  of  data.  However,  it  would  be  time  con¬ 
suming  to  also  check  discretionary  access  rules  on  a  per-row 
basis.  In  most  DBMSs,  such  checks  are  done  at  a  higher  level, 
usually  the  database  and  table  level.  1  he  SYSDS  maintains  this 
tru  '.itional  ajiproaeh  since  it  provides  efficient  and  accurate 
discretionary  protection  of  the  data. 

Second,  the  Criteria  requirements  state  that  all  accesses  to 
named  objects  in  the  system  must  be  audited.  Even  with  the 
number  of  rows  in  a  small  database  and  the  potential  accesses 
generated  by  a  few  users,  this  requirement  could  easily  produce 
a  voluminous  and  useless  audit  trail.  In  an  effort  to  control  this 
problem  and  still  meet  the  Criteria,  it  is  expected  that  only  SO 
accesses  will  nonually  be  audited  in  the  SYSDS  although  the 
capability  will  exist  to  audit  all  successful  accesses  on  a  per  table 
or  per  user  basis.  The  SYSDS  also  allows  actions  to  be  audited 
on  a  per  command  basis.  For  example,  it  is  possible  to  audit 
only  UPDATE  and  DELETE  operations  on  a  specific  table. 
Thus,  the  SYSDS  can  audit  all  accesses  to  SOs  (i.e.,  down  to  the 
ruble  ievel)  and  died  mandatory  access  and  integrity  of  all 
requested  POs.  Although  the  capability  will  exist  to  audit  every 
access  to  each  record,  it  is  expected  that  only  anomalies  will  be 
audited  at  the  PO  level.  This  approach  controls  access  to  multi 
levci  data  while  meeting  certain  Criteria  and  application 
requirements. 

Database  Operations 

As  with  any  DBMS,  the  SYSDS  has  a  set  of  common  operations 
known  as  primary  operations.  Primary  operations  arc  per¬ 
formed  directly  against  POs,  although  in  the  execution  of  each 
primary  operation  there  is  discretionary  access  validation  for 
each  operation  for  all  SOs  referenced  in  the  operation.  Only 
four  of  these  operations  are  discussed  here.  The  following 
paragraphs  present  an  overview  of  these  primary  operations. 

Select.  The  Select  operation  retrieves  rows,  or  combinations  of 
rows,  trom  one  or  more  tables  in  the  database.  Priot  to  selecting 
rows,  the  TCB  validates  discretionary  access  on  all  SOs  (i.e.,  the 
database  and  the  table)  rcfeK.ieed  in  the  selection  criteria. 
Again,  discretionary  access  is  based  on  a  pcr-command  basis  so 
it  is  possible  to  not  have  SELECT  access  to  a  particular  table. 
The  1C  B  also  validates  the  security  label  of  each  row  satisfying 
the  selection  criteria  and  retrieves  only  those  rows  dominated  by 
the  login  level  of  the  subject. 

Update.  The  update  operation  modifies  one  or  more  columns 
within  an  existing  row.  Prior  to  performing  the  update,  the  TCB 
validates  discretionary  access  on  the  SOs  referenced  in  the  up- 
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date  criteria.  The  TCB  perf  orms  mandatory  access  validation  on 
the  row  to  be  updated.  l  or  an  update,  the  subject’s  login 
clearance  must  dominate  the  -  .urity  label  of  the  row  to  be 
modified.  After  the  update,  the  row  inherits  the  login  level  of 
the  subject  which  performed  the  modification,  and  the  TCB 
recalculates  the  CRC  of  the  data  page  on  which  the  row  resides. 

Insert.  The  insert  operation  places  new  rows  into  one  or  more 
tables.  Prior  to  performing  the  insert,  the  TCB  validates  discre¬ 
tionary  access  to  the  SOs  under  consideration.  Each  new  row  in¬ 
serted  into  the  table  inherits  the  login-level  of  the  subject. 

Delete.  The  delete  operation  removes  exisiing  rows  from  the 
table.  The  TCB  validates  discretionary  access  to  the  SOs 
referenced  in  the  operations.  The  TCB  also  performs  mandatory 
access  validation  on  the  rows  to  be  deleted.  Prior  to  the  delete, 
the  TCB  will  ensure  that  the  security  label  of  each  row  to  be 
deleted  is  dominated  by  the  login-level  of  the  subject.  Subjects 
ate  not  allowed  to  delete  rows  to  which  they  do  not  have  access. 

Integrity 

As  already  mentioned,  integrity  is  of  primary  concern  to 
database  management  system  designers.  However,  the  Criteria 
docs  not  present  specific  integrity  guidelines.  The  SYSDS  model 
addresses  the  problems  of  data  corruption,  i.c.,  the  problem  of 
data  modification  rather  than  data  access.  The  SYSDS  policy 
encompasses  accidental  modification,  unauthorised  modifica¬ 
tion,  as  well  as  integrity  checking  for  the  correctness  of  database 
data. 

Biba  lias  'imposed  several  solutions  to  the  integrity  oroblcm 
including  his  str.c'.  integrity  policy,  the  low-water  mat  a  policy, 
and  the  ring  policy  [BIBA77].  Unfortunately,  many  other 
researchers  have  found  these  theoretical  policies  overly  restric¬ 
tive.  For  example,  the  strict  integrity  policy  restrictions  are 
unwieldy  in  application.  If  a  program  read-  data  of  low  integ¬ 
rity,  it  cannot  write  data  of  high  integrity.  This  led  Schell  to  pro¬ 
pose  a  special  case  of  the  strict  integrity  policy  in  which  read 
access  and  execute  access  are  distinguished  [SCHL86].  Bocbert 
and  Kain  found  that  hierarchical  integrity  policies,  which  bind 
integrity  levels  to  subjects  as  well  as  objects,  are  difficult  to 
apply  in  application  in  tnat  they  have  excessive  reliance  on 
“trusted"  subjects  (BOEB85].  Finally,  Eaodwchr  omitted  integ¬ 
rity  levels  from  the  Military  Message  System  security  model 
because  there  is  no  mechanism  in  the  government  for  accounta¬ 
bility  with  regard  to  the  protection  of  data  against  modirieation 
[1.AND82,  LAND84). 

The  SYSDS  docs  not  implement  a  hierarchy  of  integrity  levels 
but  rather  addresses  the  concept  of  TCB  integrity  and  correct¬ 
ness  of  data  pages  and  security-relevant  objects.  The  TCB  is 
divided  into  two  hardware  domains,  forcing  an  overlay  of  least- 
privilege  on  the  code.  The  I/O  Domain  deals  directly  with  all 
hardware  elements  m  the  system  and  is  the  only  domain  capable 
of  altering  the  data  base.  The  Policy  Domain  is  the  data  base 
management  engine. 

Other  DBMSs  do  not  emphasize  the  correctness  of  data  and  the 
critically  of  well-formed  tables.  The  SYSDS  uses  the  CRC'  to 
detect  unintentional  (or  intentional)  crors  in  data  correctness. 
The  CRC  is  calculated  on  a  page  basis.  In  addition  to  this  in¬ 
ternal  CRC  check,  the  system  will  return  to  the  host  a  CRC 
calculated  over  the  da'a  row  to  assure  the  correctness  of  the  row 
while  in  transmission. 

Finally,  the  SYSDS  uses  trusted  code  to  build  security-relevant 


tables  such  as  the  login  account  tabic,  the  user  clearance  tabic, 
and  the  discretionary  access  authorization  table.  No  commercial 
system  today  can  guarantee  that  data  will  not  be  inserted  into  or 
removed  from  an  incorrect  row.  By  using  trusted  code,  the 
SYSDS  makes  it  possible  to  make  assertions  as  to  the  correctness 
of  security  relevant  tables,  assertions  which  cannot  be  made  if 
the  tables  are  constructed  by  an  untrusted  SQ1-  compiler. 


THE  SYSDS  ARCHITECTURE 
Hardware  Architecture 

The  Digital  Equipment  Corporation  (DEC*)  VAX  product  line 
is  the  target  hardware  environment  for  SYSDS.  It  provides  a 
compatible  family  of  ptice/pcrformance  machines  from  a  major 
manufacturer.  Any  machine  with  at  least  three  hardwate  do¬ 
mains  could  have  been  chosen.  In  fact,  if  the  internal  division  of 
the  TCB  into  two  parts  had  not  been  a  goal,  any  machine  with 
two  domains  could  have  been  used. 

All  VAXs,  from  the  MicroVAX  through  the  8850,  have  a 
memory  architecture  with  four  access  modes  or  domains.  The 
access  modes  arc  organized  in  a  strict  hierarchy  which  DEC  calls 
User,  Supervisor,  Executive,  and  Kernel,  going  from  least  to 
most  privileged  (Supervisor  mode  is  not  used  in  the  SYSDS 
architecture).  To  go  from  a  lower  privilege  to  higher  privilege 
requires  a  system  call.  In  this  way,  the  TCB  can  control  the  call 
and  all  data  accesses  in  the  call.  To  go  front  a  higher  to  a  lower 
privilege  domain  can  be  done  by  a  return  from  a  system  call. 

Each  page  of  memory  in  the  VAX  can  be  marked  with  the  least 
privileged  domain  that  can  read  it  and  the  least  privileged 
domain  that  can  write  it.  For  example,  a  page  can  be  marked  as 
read  by  User  mode  and  write  by  Kernel  mode,  meaning  that  all 
four  modes  can  read  the  page  but  only  the  Kernel  mode  can 
write  the  page.  This  mechanism  is  used  extensively  in  the 
SYSDS.  It  is  not  possible,  for  example,  to  allow  read  access  by 
Executive  mode  but  not  by  Kernel  mode  since  this  breaks  the 
strict  hierarchy.  The  modes  arc  used  to  provide  separation  of 
trusted  arid  untrusted  processes,  as  well  as  provide  separation  of 
functions  within  the  TCB. 

Software  Architecture 

The  SYSDS  software  architecture  is  divided  into  three  code 
bodies,  each  of  which  runs  in  its  own  hardware  access  mode  of 
the  VAX.  The  software  is  divided  into  one  untrusted  domain 
and  two  trusted  domains  comprising  the  TCB.  The  SYSDS  soft¬ 
ware  architecture  maps  directly  into  the  lour  VAX  access 
n  odes.  Figure  1 ,  SYSDS  Software  Architecture,  illustrates  the 
different  domains. 

The  I/O  Domain.  The  I/O  Domain,  executing  in  the  most 
privileged  Kernel  access  mode,  is  reserved  for  software  that 
manages  the  hardware  and  directly  manipulates  the  data  on  the 
disk,  in  cache,  or  on  the  network.  Software  in  the  I/O  Domain  is 
responsible  for: 

•  Process  Control 

•  Hardware  Control 

•  Page  Integrity. 

♦DEC.  VAX,  MicioVAX,  VMS,  and  UI.TRIX  are  trade¬ 
marks  of  Digital  Equipment  Corporation. 
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•  Index  Management 
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Figure  1.  SYSDS  Software  Architecture 


The  I/O  Domain  replaces  the  traditional  operating  system. 
Since  its  only  function  is  to  provide  a  run-time  environment  for 
the  database,  its  size  is  very  small  Excluding  device  drivers,  it  is 
its  size  will  be  approximately  2,600  C  statements.  All  estimates 
are  based  on  Sv'hase  DataServer  2.0  line  counts  of  comparable 
code,  the  device  drivers  will  be  adapted  from  ULTR1X. 

The  I/O  Domain  is  the  only  domain  which  has  write  access  to 
the  database  cache.  When  a  page  is  needed  from  the  database 
(j.e. ,  disk),  it  is  read  by  the  I/O  Domain  into  a  cache  buffer  in 
main  memory.  Each  page  has  an  ID  and  CRC  on  it  used  to  con¬ 
firm  that  the  disk  controller  read  the  correct  page  and  verify  the 
correctness  or  integrity  of  the  page  itself. 

The  Policy  Domain.  The  Policy  Domain  contains  the  entire 
security  policy  for  the  SYSDS  and  is  the  ptimary  execution 
engine  for  the  database.  The  Policy  Domain  also  includes  a 
library  of  subroutine  services  used  mainly  by  code  in  the  same 
domain.  This  library  supports  the  management  of  indices,  locks, 
pages,  and  searches.  The  Policy  Domain  runs  in  the  Executive 
mode  of  t iic  VAX  and  is  the  next  highest  privileged  access  mode 
after  the  Kernel.  Code  in  the  Policy  Domain  implements  the 
following  functional  units: 

•  Authentication 

•  Query  Execution 

•  Access  Methods 

•  Data  Dictionary  Requests 

•  Procedure  Validation 

•  Discretionary  Access  Control 

•  Mandatory  Access  Control 

•  Logging 


•  Lock  Management 

®  Page  Management 

•  Search  Management. 

User  Domain.  The  User  Domain  translates  and  compiles  SQ1. 
(the  query  language)  statements  into  procedures  which  can  be 
executed  by  the  Policy  Domain.  All  User  Domain  code  runs  in 
User  mode  on  the  VAX  and  is  considered  untrusted.  User  Do¬ 
main  code  calls  the  Policy  Domain  via  a  system  call  and  cannot 
call  the  I/O  Domain  directly.  This  code  is  nearly  identical  to  the 
existing  Sybase  DataServer  code  that  performs  the  same  func¬ 
tions.  The  functional  units  in  the  User  Domain  include: 

•  The  Compiler 

•  The  Sequencer 

«  Decision 

•  Stored  Procedures 

•  Triggers. 


THE  SYSDS  IN  OPERATION 

Figure  2  illustrates  a  scenario  tying  all  of  this  information 
together.  After  the  Policy  Domain  lias  ieceive-d  a  User  ID, 
Password,  and  Login-level  Clearance,  and  the  user  is  logged  in, 
an  untrusted  process  is  created  by  the  Policy  and  I/O  Domains 
on  behalf  of  the  user.  From  that  point  or.,  processing  requests 
are  received  in  the  TC3  and  passed  to  the  untrusted  user  process 
in  the  User  Domain  for  parsing  and  compilation.  For  example, 
commands  in  the  form  of  SQL  statements  arc  received  from  the 
host  via  a  network.  The  I/O  Domain  is  responsible  for  decoding 
the  statements  and  passing  them  to  tiic  Policy  Domain  for 
dissemination.  The  Policy  Domain  in  turn  distributes  the  com¬ 
mand  to  the  correct  user  process  executing  in  the  untrusted  User 
Domain. 


Figure  2.  SYSDS  Operations 


After  the  untrusted  uset  pioecss  receives  the  command,  it  first 
compiles  the  SQI.  statcment(s)  into  a  binary  internal  format 
called  a  Procedure,  to  be  passed  to  the  TCP  lor  execution.  The 
compilation  step  requires  a  great  deal  of  code,  and,  in  the 
SYSDS.  it  was  determined  that  all  ol  this  code  could  remain  un- 
trusn  thus  reducing  the  size  of  the  TCI1.  The  1  CB  handies  all 
aspect .  of  the  execution  of  the  Procedure  aftei  it  lias  been  com¬ 
piled,  including  the  retransmission  of  the  results  to  the  host. 
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ABSTRACT 


Sun  Microsystems  is  currently  developing,  enhancements  to  its  Sun  Workstation  and  SunOS  products  to 
create  a  Trusted  Computing  Base  to  bo  evaluated  at  the  Hi  level  In  this  pape-,  that  product  is  referred  to 
as  “Secure  SunOS”.  This  paper  describes  the  project’s  history,  status,  and  goals,  as  well  as  discussing  the 
more  interesting  aspects  of  the  Secure  SunOS  product.  This  paper  also  describes  some  of  Sun’s  future 
directions  in  the  secure  systems  marketplace. 


INTRODUCTION 

In  late  1983,  Sun  Microsystems  established  the  Sun  Federal  Sys¬ 
tems  Division  to  do  business  in  government  marketplaces.  It 
soon  became  apparent  that  computer  security  would  play  an 
important  role  in  these  markets,  and  that  Sun  would  have  to 
develop  a  Trusted  Computing  Base  (TC.'B),  based  on  its  Sun 
Workstation  and  SunOS  products,  to  be  evaluated  according  to 
the  requirements  of  the  Trusted  Computer  System  Kva’uation 
Criteria  |DoD85j.  This  work  has  been  going  on  in  earnest  for  a 
about  one  year,  and  the  purpose  of  this  paper  is  to  describe  what 
Sun  has  been  doing  and  where  Sun  is  going  in  the  computer 
security  marketplace. 

The  first  half  of  this  paper  begins  by  describing  the  history  of  the 
Secure  SunOS  project,  the  near-term  product  plans  for  secure 
computing,  development  directions  and  goals,  and  Sun’s  work  in 
UNIX  system  security  standards.  The  second  half  of  the  paper 
describes  the  more  interesting  features  of  this  initial  version  of 
Secure  SunOS,  which  is  targeted  for  the  HI  TCSl'.O  level.  The 
description  of  Secure  SunOS  does  not  attempt  to  explain  the 
underlying  SunOS  system  (Sun’s  enhanced  version  of  the  UNIX 
system),  the  basic  concepts  of  mandatory  security,  or  the 
requirements  of  the  TOSKC,  because  these  topics  have  been 
covered  well  by  other  papers  in  the  past. 


CURRENT  STATUS 

Sun  got  started  in  the  computer  security  business  only  about  a 
year  ago.  The  initial  impetus  was  provided  by  government  pro¬ 
curements  with  requirements  for  the  02  and  III  security  levels 
defined  in  the  '1XRSEC.  It  also  became  clear  that  it  would  be 
increasingly  important  to  have  an  evaluated  secure  product,  and 
morcoter,  security  features  that  were  flexible  enough  to  apply  in 
commercial  environments  as  well  as  for  government  customers. 


Because  111  is  the  highest  level  readily  achievable  by  commercial 
systems,  it  is  most  common  in  current  gove.nment  procure¬ 
ments  Although  some  procurements  specify  02,  a  B!  system 
will  satisfy  any  02  (or  01)  requirement,  as  well  as  all  Bl  require¬ 
ments.  Since  the  NOSO  evaluation  process  is  expensive  and 
time-consuming,  Sun  decided  to  forego  a  02  evaluation  and 
have  Secure  SunOS  imiialiv  evaluated  for  Hi.  The  main  conse¬ 
quence  of  this  decision  is  that  an  evaluated  version  oT  SunOS 
will  be  delivered  somewhat  later  than  might  have  been  possible 
had  only  the  02  features  been  added,  but  this  additional  delay  is 
relatively  small.  Itven  though  Secure  SunOS  will  not  be  delivered 
this  year,  all  major  02  features  will  be  present  (though 
uncvahiatcd)  in  the  next  release  of  standard  SunOS. 

In  keeping  with  Sun’s  commitment  to  develop  and  support  stan¬ 
dards  for  UNIX  systems.  Sun  is  working  with  several  standards 
groups,  and  some  other  vendors,  to  settle  on  common 
definitions  for  security  labels,  password  protection,  auditing, 
access  control  lists,  and  so  forth. 

Adding  basic  C2/B1  security  features  to  a  UNIX  system  surb  as 
SunOS  is  straightforward.  The  challenge  lies  in  making  those 
features  both  powerful  and  sufficiently  easy  to  use  that  they  can 
be  applied  in  many  environ  men  Us,  not  just  that  of  federal 
government  classified  information  processing  The  system  roust 
also  be  designed  in  a  way  that  docs  not  conflict  with  user’s 
expectations  for  a  standards-eonforming  UNIX  system  Sun  is 
committed  U>  producing  technically  advanced  secure  systems, 
with  features  beyond  the  relatively  simple  requirements  of  the 
Criteria.  This  is  particularly  important  for  the  commercial  and 
educational  marketplaces,  where  mandatory  access  control 
mechanisms  may  not.  fit  an  organ i/,at.ion’s  needs,  but  where 
increased  security  and  administrative  control  arc  very  important. 


CURRENT  PRODUCT  PLANS 


The  primary  focus  of  Sun’s  elfort  is  the  Secure  SunOS  product. 
This  is  a  system  intended  to  meet  the  Bl  requirements  of  the 
TCSHC,  and  is  currently  nearing  the  end  of  its  initial  dcvelop- 
m cut  cycle.  The  first  result  of  this  work  is  the  package  of  “C2 
Features"  to  be  delivered  in  SunOS  Release  4.0. 


UNIX  is  a  registered  trademark  of  AT&T 

NFS  and  SunOS  are  registered  trademarks  of  Sun  Microsystems,  Inc. 
Xenix  is  a  registered  trademark  uf  Microsoft. 
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Hie  C2  Features  Package 


Standards 


The  “02  Features**  package  \:i  primarily  intended  to  give  t-nslo- 
niers  an  early  chance  to  ex  pc  runs*  nt  with  the  Auditing  mechan¬ 
ism  that  will  he  fully  implemented  in  Secure  SunOS.  The  pack¬ 
age  also  includes  protection  for  user  passwords,  additional  docu¬ 
mentation,  and  some  initial  support  for  the  labeling  features  in 
Secure  SunOS.  With  the  “(*2  Features'*  package  fully  installed, 
SunOS  Release  10  will  satisfy  ah  the  major  (*2  requirements  of 
the  TUSEO.  It  was  not  submitted  for  evaluation  primarily  to 
save  the  effort  of  a  full-scale  security  evaluation  for  the  SunBl 
product,  and  also  because  it  is  incomplete  m  minor  areas 

This  proved  to  be  a  wise  decision,  because  it  allowed  us  to  put 
in  an  y  of  the  underpinnings  of  Secure  SunOS  into  place  much 
earlier  than  would  otherwise  have  been  possible.  It  also  allows 
us  a  good  chance  to  tune  the  audit  mechanism  and  make  it 
easier  to  use;  since  the  “led”  of  an  audit  facility  ls  very  difficult 
to  evaluate  without  experience  using  it,  this  is  very  important. 

TTie  Secure  SunOS  Product 

Secure  SunOS  is  an  independent,  product,  derived  from  the 
current  version  of  SunOS,  but  developed  and  tested  separately. 
Eventually,  the  security  features  in  each  Secure  SunOS  release 
are  expected  to  become  part  of  standard  SunOS.  Initially,  how¬ 
ever,  it  is  a  separate  product  to  ensure  that  the  NUSO  evaluation 
process  runs  as  smoothly  as  possible:  since  the  main  goal  for 
Secure  SunOS  is  111  security,  it  can  be  changed  during  the 
evaluation  process  much  more  easily  than  SunOS,  which  must 
respond  to  a  wide  variety  of  requirements.  Having  a  separate 
Secure  SunOS  product  also  allows  us  to  coordinate  product 
release  with  the  forma!  cvjduu'k'n.  rather  than  being  tied  to  the 
regular  release  schedule.  Nonetheless,  it  is  really  just  a  version 
of  SunOS,  and  the  two  products  are  kept  closely  tied. 

The  goals  of  Secure  SunOS  are: 

+  Conformance  with  NOSC  Hi  criteria 

•  Keeping  the  UNIX  “feel”  in  a  secure  system 

•  Useful  in  commercial  as  well  as  government  applications 

•  Compatibility  with  the  standard  SunOS  specification 

•  Minimal  change  to  standard  SunOS  interfaces 

•  Operation  in  standard  Sun  network  environment 

•  Extensibility  to  support  additional  security  features 

'fhe  Hi  level  was  chosen  to  meet  the  dual  goals  of  satisfying  a 
large  number  of  procurements  and  providing  a  product  in  a  rea¬ 
sonable  timeframe.  Although  Sun  is  considering  higher  TCSEC 
levels,  the  initial  emphasis  is  on  security  features  rather  than 
internal  assurances,  on  the  assumption  that  the  customers  need 
to  gain  experience  with  those  features  before  they  will  know 
what  they  really  want  in  a  more  secure  system.  Secure  SunOS 
therefore  includes  some  of  the  security  features  required  at  H2 
ami  B3:  devire  labels,  realtime  audit  alarms,  etc.,  oven  though  it 
is  only  being  evaluated  foi  Ml.  The  security  policy  and  descrip¬ 
tive  toj>- level  specification  are  also  written  to  satisfy  the  B2 
requirements. 


FUTURE  DIRECTIONS 

In  genera!  terms,  Sun  will  rnhuii'O  Secure  SunOS  in  response  to 
customer  requirements,  but  there  arc  some  specific  plans  for 
wotk  in  the  are .ts  described  below. 


Sun  is  working  with  other  vendors  and  the  Nl-SC  towards  a 
Secure  UNIX  system  standard,  'fhe  standards  work  is  being  done 
under  the  auspres  of  the  IM 003.1  Portable  Operating  System  for 
Computer  Environments  working  group  of  the  HT,K  Computer 
Society  Technical  Committee  on  Operating  Systems  and  the 
/usr/group  Technical  Committee  Subcommittee  on  Security. 
The  latter  group  is  responsible  for  preparing  all  security- related 
inputs  to  the  IEEE  POSIX  committee. 

Network  Security 

Because  the  Sun  system  is  a  distributed  collection  of  worksta¬ 
tions  and  servers  connected  by  a  network,  Sun  has  a  more  press¬ 
ing  interest,  in  network  security  than  many  other  vendors  The 
basic  SunOS  architecture  allows  a  collection  of  workstations  to 
appear  as  a  single,  distributed,  TUB.  Therefore,  for  evaluation 
purj»oses(  an  entire  Secure  SunOS  configuration  is  considered  as 
a  single  “system”,  all  of  whose  hardware  must  be  physically 
secure.  Even  in  environments  where  hardware  is  not  wholly 
secure,  the  “secure  booting”  mcch  'sni  described  below*  will 
provide  sufficient  protection  in  man  nv  iron  incuts. 

In  addition,  although  the  NOSC  I  evaluation  will  not  cover  such 
configurations,  Sun  plans  for  Secure  SunOS  to  operate  compati¬ 
bly  when  connected  lo  networks  cont**;nmg  non-Sectirc  SunOS 
machines  (either  Sun  machines  or  others).  Non-Secure  SunOS 
machines  will  be  treated  as  single-level  systems.  Finally,  all 
Secure  SunOS  systems  will  be  able  to  use  the  “secure  network¬ 
ing”  mechanisms  in  SunOS,  which  use  public-key  encryption  to 
ensure  secure  authentication  even  if  the  network  contains 
u ii trusted  hardware.  Again,  in  the  NOSO-evaluated  ill  environ¬ 
ment*  this  will  be  unnecessary  because  the  hardware  itsell  must 
be  secured,  these  features  will  be  useful  in  other  environments. 

Co^apartmented  Mode  Workstation 

For  workstations,  in  addition  to  the  NOSC  Bl  requirements, 
there  is  an  additional  set  of  security  requirements  defined  by 
MITRE  for  the  Defense  Intelligence  Agency  [  WoodwardSfij . 
'Pbe  primary  additional  feature  specified  in  that  document  is 
“floating”  labels,  which  provide  a  mechanism  for  tracking  the 
sensitivity  label  of  a1!  data  which  served  as  input  to  an  object, 
such  as  all  the  processes  which  wrote  into  a  file,  or  all  the  data 
written  to  a  window.  Sun  is  planning  to  build  extensions  into  a 
future  release  of  Secure  SunOS  to  satisfy  these  requirements. 
Th  esc  features  will  be  provided  on  top  of,  not  instead  of,  the 
basic  Hi  functions. 


Administrative  Interfaces 

Closely  related  lo  the  inherent  presence  i  f  a  network  in  the 
Secure  SunOS  configuration  an  the  attendant  problems  of 
administering  a  widely  distributed  collection  of  individual 
machines.  Sun  will  be  developing  administrative  tools  and  inter¬ 
faces  to  make  this  simpler,  and  also  to  allow  subdivision  of 
administrative  roles  and  res|x>nsibililies. 

Higher  Criteria  Levels 

Sun  has  not  yet  decided  how  to  approach  the  higher  TCSICC  lev¬ 
els,  but  will  certainly  do  so  as  market  requirements  demand, 
'nms  Tar,  the  focus  of  Secure  SunOS  lias  been  on  security 
features,  mechanisms  customers  can  actually  use  and  experiment 
with,  and  incorporate  into  their  own  applications.  Although  Sun 
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considers  the  Secure  SunOS  TCB  to  have  a  sound  internal  archi¬ 
tecture,  it  is  quite  large,  and  was  not  engineered  to  meet  the  B2 
(or  B3)  requirements.  Rather  than  building  a  brand  new  B2/B3 
system  now,  however,  Sun  plans  to  wait  and  gain  more  experi¬ 
ence  with  the  new  features  provided  by  Secure  SunOS,  to  Know 
what  to  keep  and  what  to  leave  out. 


MAJOR  FEATURES  OF  Secure  SunOS 

All  UNIX  system-derived  secure  systems  face  a  similar  set  of 
design  decisions  for  implementing  security  in  the  kernel,  how  to 
label  files,  how  to  handle  directories,  what  to  do  about  interpro¬ 
cess  communication,  etc.  For  the  most,  part,  these  issues  are 
addressed  in  Secure  SunOS  the  same  way  they  have  been  in 
other  “secure  UNIX”  systems,  such  as  IBM’s  Secure  Xenix,  the 
I.INUS  IV  prototype  developed  at  MITRE,  etc.  Like  those  sys¬ 
tems,  Secure  SunOS  follows  the  same  basic  model  as  Multics  in 
applying  mandatory  security: 

•  Processes,  files,  directories,  and  all  other  objects  have 
labels,  and  ill  the  initial  release,  labels  "-"nport  2.r>0  hierarch¬ 
ical  mandatory  security  levels  and  G-I  m  n-hierarchical  man¬ 
datory  security  categories. 

•  The  formal  security  model  for  the  system  is  the  Unified 
Multics  version  of  the  Bell  and  La  Radula  model  described 
in  [Bcll76] . 

•  For  most  objects,  the  model  is  restrictively  interpreted  to 
allow  read-downs  (reading  data  with  a  lower  label  than  the 
process),  but.  not  write-ups  (modifying  data  with  a  higher 
label  than  the  process).  This  is  done  to  simplify  the  imple¬ 
mentation  auu  eiiiu iu.vto  a  variety  of  covert  channels  at  the 
design  stage. 

•  Labels  in  the  file  system  hierarchy  are  monotonically  non- 
decreasing;  all  objects  in  a  directory  have  the  same  label  as 
the  directory  itself,  except  for  directories,  which  may  be 
“upgraded”  (have  a  higher  label  than  their  containing 
directory). 

•  The  initial  version  of  Secure  SunOS  does  not.  include  any 
“least  privilege"  mechanism  to  replace  use  of  root  as  the 
only  form  of  privilege.  Sun  is,  however,  working  with  the 
/usr/group  standards  committee  to  define  such  a  mechan¬ 
ism  for  eventual  inclusion  in  the  I’OSlX  standard  and 
future  versions  of  Secure  SunOS 

•  Tlte  initial  version  of  Secure  SunOS  also  does  not  include 
any  form  of  Access  Control  Lists  (AOl.s),  and  again,  Sun  is 
working  with  the  standards  committee  to  define  an  ACL 
interface  for  ROSIX  and  future  Secure  SunOS  systems. 

The  remainder  of  this  paper  describes  some  of  the  Secure 
SunOS  features  that  are  unusual  and  how  they  are  different  from 
other  “secure  UNIX”  systems. 

Labeled  Windows 

Probably  the  most  important  feature  of  Secure  SunOS  is  dial  the 
on  screen  windows  arc  considered  objects  by  the  TOR,  and  have 
labels.  This  allows  a  user  at  a  workstation  to  view,  simultane¬ 
ously,  activity  of  processes  with  several  different  labels.  The 
user  can  interact  with  these  processes  simply  In  moving  the 
mouse  from  one  window  to  another,  unlike  conventional  man¬ 
datory  access  control  systems,  where  often  a  lugoiit/logui 


sequence  is  required  every  time  labels  are  changed  Data  can 
even  be  moved  between  windows  of  differing  security  labels, 
provided  that  the  mandatory  access  control  rules  arc  followed. 

A  user  interacts  with  the  system  by  logging  in  at  some  level  and 
creating  windows  of  that  level  and  below. 

Auditing 

Auditing  in  Secure  SunOS  is  done  on  the  basis  of  event  classes 
Each  process  has  an  audit  state,  specifying  which  event,  classes 
arc  audited  for  that  process  The  audit  state  specifies  separately 
whether  to  audit  a  particular  class  for  successful  operations  or 
tailed  attempts,  so  that,  for  instance,  all  access  denials  will  be 
audited,  but  only  successful  write  accesses  (not  reals)  will  be. 

There  is  a  system  default  set  of  audit  classes,  and  eaeli  user  has 
two  sets  that  modify  the  system  default.  The  administrator  may 
specify,  on  a  per-user  basis,  which  event  classes  arc  always 
audited  for  the  user,  regardless  of  system  defaults,  and  which 
event  classes  are  never  audited. 

At  present.,  Secure  SunOS  defines  13  audit  classes,  which  include 
operations  such  us  data-rcad  (open  for  read,  file  status  inquiry, 
etc),  data-writr  (open  for  write,  etc),  data- arrets- change  ( ch  an  go 
file  permissions,  change  owner,  etc  ),  daia-ercate  (create,  delete, 
link,  etc.),  login  (interactive  login,  logout,  use  of  sti,  process 
created  by  at.  etc.),  and  others.  Audit  messages  are  also  gen¬ 
erated  for  all  administrative  and  privileged  activity,  identifying 
the  specific  operation  performed  as  far  as  possible.  Administra¬ 
tive  events  arc  audited  specifically,  not.  just  as  the  administrator's 
access  to  a  file,  for  instance,  use  of  ripw  to  change  the  jiaxgwd  file 
(where  user  registrations  are  kept)  audits  the  change  between 
the  original  jnisswd  ii ic  and  ilie  modified  version. 

Auditing  in  a  Network  Environment 

Because  many  of  the  machines  in  a  Secure  SunOS  configuration 
are  typically  diskless  workstations,  audit  messages  arc  written 
across  the  network.  Each  machine  has  its  own  audit  daemon, 
which  collects  the  audit  messages  generated  locally  and  writes 
them  out  to  an  audit  file.  The  audit  file  is  written  using  normal 
file  I/O,  but  by  using  the  Network  File  System  (NFS)  it  is  possi¬ 
ble  foi  the  audit  file  to  he  located  on  an  arbitrary  machine 
nwherc  in  the  network. 

If  an  audit  file  fills  up,  or  if  the  machine  containing  it  goes 
down,  each  local  audit  daemon  that  was  using  that  liie  detects 
the  error  and  tries  to  create  another  audit  file  in  a  different  direc¬ 
tory.  Because  each  local  audit  daemon  has  a  list  of  directories  to 
try  when  creating  audit  files,  this  is  a  very  robust  system  it  is 
very  likely  that  audit  messages  will  find  a  home,  even  though 
they  may  he  scattered  among  many  machines 

Each  machine  in  the  system  is  res|Kinstlde  for  auditing  its  own 
activity  This  is  safe  because  the  machines  arc  required  to  be 
physically  secure,  and  because  the  non-priv Urged  users  do  not 
have  the  capability  of  logging  in  ns  root  or  bringing  the  machines 
up  in  single-user  mode.  Thus,  access  to  a  machine  docs  not 
present  the  opportunity  to  hteach  even  that  machine's  own  secu¬ 
rity 

Audit  Reduction  and  Display 

Because  multiple  audit  files  air  an  inherent  feature  of  auditing  in 
a  distributed  environment-,  Secure  SunOS  treats  this  as  a  feature. 
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rather  than  :ui  inconvenience.  The  administrator  wishing  to 
viow  the  audit  trait  uses  tin*  NFS  to  access  nil  the  audit  lilos  that 
are  scattered  among  directories  on  machines  all  over  the  system, 
and  the  audit  tool  puts  those  records  back  in  order. 

The  audit  display  tool  is  normally  used  to  display  the  output  of 
another  program,  auddrt.durr.,  which  combines  the  audit,  it* cords 
from  many  audit  files  and  writes  them  out  in  time --sorted  order 
for  printing  or  report  generation.  Selection  of  audit,  messages 
( hy  type,  string  match,  time  of  day,  user  name,  security  level, 
etc.)  is  performed  in  auditrcducc,  so  that  a  report  generation  pro¬ 
gram  need  no.  have  any  selection  options  of  its  own.  These 
tools  also  make  it  easy  for  the  administrator  to  gather  multiple 
audit  files  back  into  one  place,  keep  old  audit  files  on  tape,  and 
even  keep  selections  fiom  audit  tiles  online  (such  as  a  tile  con¬ 
taining  only  login  records,  but  from  the  last  six  months). 


Hidden  Subdirectories 

Kvory  “Secure  UNIX  system”  faces  tlu*  problem  of  dealing  with 
shared  directories  for  temporary  tiles.  In  Secure  SunOS,  as  in 
IBM  s  Workstation  Xenix,  the  temporary  directories  are  special 
in  that  normal  references  to  them  actually  translate  to  references 
to  a  subdirectory,  of  which  there  is  one  for  cacti  d ill’ e rent  label 
A  directory  which  causes  this  indirection  (such  as  ft  tup)  is  known 
as  ;»  “hiding"  directory,  and  its  subdirectories  (one  for  each 
security  label)  are  known  ns  “hidden  subdirectories”.  Those 
hidden  subdirectories  ar«-  created  dynamically  the  first  time  a 
process  tries  to  reference  one  that  doesn’t  exist.  Because  they 
are  created  automatically,  it  is  safe  to  delete  them  fas  I n|ig  as 
they  arc  empty)  at  any  time.  Because  use  of  hidden  subdirec¬ 
tories  in  Secure  SunOS  is  com  rolled  on  a  pc:-durv  iofy  b.isi.-,  this 
facility  is  used  not.  only  for  /Imp,  but  also  for  fu# r/tnip,  some  of 
the  directories  in  fuar/spntd,  etc. 


Physical  Security 

I*' very  machine  in  a  Secure  SunOS  configuration  must  be  physi¬ 
cally  secure.  What  this  means  varies  from  customer  to  custo¬ 
mer,  but  Sun  can  provide  a  variety  of  protective  packaging*  that 
can  make  it  arbitrarily  difficult  for  an  unauthorized  user  to 
breath  the  hardware  integrity  of  a  machine.  Modified  PROMs 
prevent  the  machines  from  being  booted  in  siiiglr-us«*r  mode  or 
from  other  than  the  default,  version  of  the  kernel  without  a  spe¬ 
cial  (per- machine)  password.  The  pci-maeliiiie  password  may  be 
changed  by  a  system  administrator 
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ABSTRACT 


Computer  virus  defenses  can  be 
categorized  using  the  following  six  grouping 
schemes: 

Appearance  versus  Behavior, 
Prevention  versus  Detection, 
Executable  versus  Source, 

Required  Protection, 

Performance,  and 
Ease,  to  Implement. 

Each  scheme  is  explained,  and  examples  are 
used  to  clarify  each  scheme.  This  taxonomy 
will  aid  in  evaluating  virus  defenses  and 
provide  a  foundation  for  designing  new  virus 
defenses. 


INTRODUCTION 

A  computer  virus  is  a  piece  cf  harmful 
code  that  is  hidden  in  an  otherwise  normal 
program.  A  virus  is  also  able  to  write  a 
copy  of  itself  to  (or  "infect")  other 
programs. [5]  This  capability  makes  a  virus 
especially  dangerous  to  computer  systems 
because  a  virus  is  likely  to  be  harder  to 
remove  and  is  likely  to  have  access  to  more 
computer  resoures  than  malicious  code  that 
does  not  have  this  capabilty.  A  virus  could 
propagate  for  a  certain  period  of  time  until 
some  event  triggers  it  to  perform  its  harmful 
action.  Because  of  the  danger  that  viruses 
pose  to  computer  systems,  it  is  important  to 
develop  defenses  against  them. 

The  purpose  of  this  paper  is  to 
categorize  computer  virus  defense  mechanisms. 
By  presenting  virus  defenses  in  an  organized 
manner,  this  paper  should  help  virus 
researchers  find  defense  categories  that 
might  be  missing  and  to  formulate  more, 
defenses  for  some  of  the  categories.  Six 
different  schemes  are  described  for 
classifying  computer  virus  defenses  and 
examples  are  given  to  clarify  each  scheme: 

Appearance  versus  Behavior, 

Prevention  versus  Detection, 

Executable  versus  Source, 

Required  Protection, 

Performance,  and 

Ease  to  Implement. 


The  first  part  of  this  paper  describes 
four  defense  measures  that  will  be  used  as 
examples.  The  bulk  of  this  paper  is  the 
taxonomy  which  looks  at  the  six 
categorization  schemes.  The  paper  explains 
each  scheme  and  describes  how  and  why  each 
example  fits  into  the  various  categories. 
Appendix  A  contains  a  matrix  that  shows  a 
wide  range  of  defense  measures  and  how  they 
are  cataloged.  Also  included  in  Appendix  A 
is  a  list  of  short  desci options  of  the 
defense  measures.  Appendix  B  consists  of 
definitions. 


The  following  are  four  examples  of  virus 
defenses  that  will  be  used  to  clarify  the 
taxonomy.  These  examples  are  a  subset  of  the 
virus  defenses  described  in  Appendix  A. 

1.  coding  Style  Analyzer 

A  coding  style  analyzer  uses  the 
structure  and  content  of  a  program  to 
determine  how  many  different  programmers 
contributed  to  the  program  and  what  sections 
of  code  were  written  by  each.  A  coding  style 
analysis  is  related  to  the  analysis  of  such 
things  as  handwriting  and  structure  of 
sentences  to  authenticate  the  author  of  a 
book.  An  example  of  some  coding  style 
indicators  at  the  source  code  level  might  be 
the  number  of  spaces  used  to  indent  a  While 
Loop,  the  frequency  of  comments,  and  the 
kinds  of  instructions  used.  Such  an  analyzer 
can  be  used  to  detect  the  presence  of  a  virus 
because  most  virus  code  will  have  a  different 
coding  style  than  the  host  program,  and  the 
virus  programmer's  style  is  likely  to  be 
present  in  all  the  infected  programs. 

2 •  Prefix  and  Postfix  Checker 

Primitive  viruses  will  probably 
reside  in  the  beginning  or  end  of  host 
programs  and  will  infect  host  programs  with 
exact  replicas  of  themselves.  A  prefix  and 
postfix  checker  compares  the  beginning  and 
end  of  files  to  Gee  if  a  group  of  files  have 
the  same  beginning  or  the  same  end.  A  group 
of  files  with  identical  prefixes  or  postfixes 
are  likely  to  contain  a  virus. 


3 .  ROM  Devices 

Programs  may  be  put  into  read 
only  memory  (ROM)  devices  to  prevent  viruses 
from  infecting  critical  programs.  Programs 
stored  in  such  devices  cannot  be  modified. 
Adequate  measures  must  be  taken  to  make  sure 
that  only  uninfected  programs  are  stored  in 
the  ROM. 


EXAMPLE  VIRUS  DEFENSES 
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4 .  Intrusion  Detector 

An  intrusion  detector  is  a 
defense  measure  that  monitors  the  activities 
in  a  system  to  determine  if  it  is  under 
attack.  The  detector  does  this  by  comparing 
current  actions  with  past  actions  to  see  if 
something  out  of  the  ordinary  is  occurring. 
This  defense  can  be  used  to  detect  many 
different  types  of  intrusion,  including 
viruses.  Some  distinguishing  actions  that 
would  indicate  a  possible  virus  attack  would 
be  accessing  many  filas,  searching 
directories,  and  writing  to  executable 
files .  [  4  ] 


TAXONOMY 


A .  Appearance  Versus  Behavior 

file  appearance-versus-behavior 
categorization  distinguishes  between  virus 
defenses  that  detect  or  prevent  infection  by 
program  appearance  and  those  that  detect  or 
prevent  infection  by  program  behavior.  An 
appearance  defense  considers  the  contents  of 
a  program,  whereas  a  behavior  defense 
considers  the  actions  of  a  program. 
Appearance  defenses  work  before  the  host 
program  is  executed,  and  behavior  defenses 
work  during  execution. 

Both  kinds  of  defenses  have  their 
limitations.  For  a  given  program  it  may  not 
be  possible  to  absolutely  determine  by  its 
cippcursncc  if  thst  contiins  21  virus ■ 
These  defenses  make  an  educated  guess  as  to 
whether  a  program  contains  a  virus.  For  every 
defense,  however,  a  clever  virus  can  probably 
be  written  to  outsmart  that  defense.  The 
behavior  defenses  in  many  cases  can  be 
thwarted.  A  clever  virus  would  behave  in  a 
subtle  way  so  that  its  actions  will  not  seem 
out  of  the  ordinary  for  the  host  in  which  it 
resides. 

The  coding  style  analyzer  is  an 
example  of  an  appearance  defense  because  it 
looks  at  the  contents  and  structure  of  a 
program  to  determine  the  author (s)  of  the 
program.  The  prefix  and  postfix 
checker  also  fits  in  the  appearance  category. 
This  checker  looks  at  the  beginning  and  end 
contents  of  files  to  find  identical  prefixes 
and  postfixes. 

ROM  devices  qualify  for  the  behavior 
category  since  they  prevent  viruses  from 
performing  the  action  of  writing  to  the  files 
stored  in  ROM.  The  intrusion  detector  is 
another  behavior  defense  because  it  monitors 
actions . 


B.  Prevention  Versus  Detection 

All  virus  defense  measures  fall  into 
one  of  two  categories:  prevention  or 
detection.  Prevention  defenses  are  those 
that  stop  virus  propagation.  Some  of  the 
actions  involved  in  propagation  that  can  be 
prevented  are  writing  to  executable  files  and 
accessing  a  file  that  has  been  touched  by  too 
many  processes.  Prevention  defenses  will 
control  and  limit  access  to  files.  Detection 
defenses  recognize  virus  attacks  but  do  not 


have  the  power  to  stop  a  virus.  Detection 
measures  could  be  considered  a  typo  of 
prevention,  however,  because  the  system 
security  officer  can  shut  down  the  system  to 
prevent  further  damage  once  the  virus  has 
been  detected. 

Prevention  defenses,  by  definition, 
involve  restricting  an  action  and  will  only 
involve  behavior  measures.  ROM  devices  will 
prevent  virus  spread  because  they  are 
designed  such  that  the  information  stored  on 
them  cannot  be  altered. 

Detection  defenses  are  usually 
appearance  measures.  A  coding  style  analyzer 
detects  the  presence  of  a  virus  after  the 
host  program  has  been  infected.  l't  will 
indicate  an  additional  programmer  than  the 
one/s)  who  wrote  the  host  program.  The 
prefix  and  postfix  checker  will  detect  a 
virus  that  resides  in  the  beginning  or  end  of 
files  after  it  has  spread  to  several  files. 
The  intrusion  detector  watches  for  telltale 
actions. 


C .  Source  and  Executable 

Virus  defenses  can  be  partitioned 
based  upon  whether  they  monitor  source  code 
or  executable  code.  Many  of  the  proposed 
defenses  lister1  in  Appendix  A  are  effective 
for  both  source  and  executable  code.  Since 
viruses  can  reside  and  propagate  to  either 
kinds  of  code,  it  is  important  to  defend 
against  viruses  in  both  kinds  of  code. 

A  coding  style  analyzer  works  best 
on  source  code  because  source  code  will  bear 
all  the  marks  of  its  author.  Executable 
code,  on  the  other  hand,  is  the  result  of  a 
compiler  converting  source  code  into  a 
standard  form  that  a  machine  can  understand. 
The  resulting  executable  code  will  not  have 
all  of  the  marks  found  in  source  code  such  as 
indentations  and  comments.  The  more 
transformation  processes  that  a  program  goes 
through,  the  less  marks  it  will  have  of  the 
author. 


The  prefix  and  postfix  checker  will 
work  well  with  source  and  executable  code. 
If  a  virus  propagates  by  writing  exact  copies 
of  itself  to  the  beginning  or  end  of 
programs,  making  the  bytes  exactly  alike,  the 
prefix  and  postfix  checker  will  detect  this 
reguardless  of  the  type  of  code. 


Since  the  information  in  a  ROM 
device  cannot  be  changed,  a  ROM  is  used  to 
store  the  final  executable  version  of 

programs.  For  the  most  part,  source  code 
only  needs  to  reside  in  the  development 

system,  and  not  in  the  target  system.  It 

would  usually  not  make  sense  to  store  source 
code  on  a  ROM  device.  A  ROM  device  is, 
therefore,  considered  a  defense  for 

executable  code. 


The  intrusion  detector  concerns 
itself  with  the  actions.  This  defense  falls 
under  the  executable  category  because  source 
code  does  not  act  but  executable  code  does. 


D.  Required  Protection 

Virus  defense  mechanisms  must  be 
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protected.  The  protection  needed  for  each 
defense  gives  another  way  to  classify  virus 
defenses.  The  categories  are  based  on  what 
needs  protection,  and  what  type  of  protection 
is  needed.  The  number  of  different 
protections  and  the  kind  of  protection  needed 
will  have  an  impact  on  the  vulnerability  of  a 
defense  measure.  Except  for  the  ROM  devices, 
all  the  measures  included  in  this  paper  must 
be  read-,  write-,  and  execute-protected. 

Each  defense  must  be  read-protected 
so  that  viruses  cannot  learn  the  threshold 
values  and  other  information  that  would  help 
them  evade  the  defense.  Write-protection  is 
necessary  so  that  the  defense  cannot  be 
modified  to  ignore  or  help  a  virus.  Each 
defense  must  be  execute-protected  to  insure 
that  it  is  ca]  led  when  it  is  supposed  to  be 
called  and  that  the  virus  does  not  execute 
the  defense  in  order  to  see  if  it  would  pass 
or  fail.  These  three  protection  needs  will 
not  be  enumerated  for  each  defense. 

The  coding  style  analyzer  requires 
protection  of  data  that  it  stores  temporarily 
while  it  is  running.  The  file  attributes 
that  the  defense  analyzes  must  be  read- 
protected  so  that  a  virus  will  not  know  what 
attributes  are  being  analyzed. 

The  prefix  and  postfix  checker  also 
needs  read-protection  of  the  size  and  extent 
of  its  search  and  comparisons. 

A  ROM  requires  the  physical 
protection  of  the  computer  to  prevent  an 
attacker  from  replacing  the  ROM  with  a  virus- 
infected  ROM.  Once  a  program  has  been 
written  to  a  ROM  device,  it  cannot  become 
infected. 

The  intrusion  detector  requires 
read-  and  write-  protection  of  long-term  and 
temporary  data.  The  long-term  data  that 
needs  protection  is  the  audit  records  that  it 
uses  to  determine  the  expected  behavior  of 
the  system.  The  temporary  data  that  must  be 
protected  is  the  expected  behavior  patterns 
which  frequently  change. 

E.  Performance 

The  effect  that  a  defense  measure 
has  on  the  performance  of  a  system  gives 
another  grouping  of  the  defenses.  This  paper 
considers  the  following  aspects  of 
performance:  the  time  it  takes  for  the 
defense  to  execute,  the  amount  of  primary 
memory  required  by  the  defense  program,  the 
frequency  of  use,  and  the  affect  of  the 
defense  on  the  throughput  of  individual 
programs.  The  affect  on  throughput  is  a 
function  of  the  other  aspects  of  performance. 

The  coding  style  analyzer  will  be 
complex  and  will,  therefore,  take  a 
relatively  long  time  to  execute.  The  coding 
style  analyzer  will  take  longer  to  run  than 
the  prefix  and  postfix  checker  because  of  its 
complexity.  The  difference  in  run  time 
because  of  complexity  will  be  multiplied  by 
the  number  of  files  that  need  to  be  checked. 
This  analyzer  will  require  a  moderate  amount 
of  memory  for  its  code  and  the  file 
attributes  it  must  analyze.  After  it  checks 
one  file,  the  coding  style  analyzer  will  not 


need  the  data  generated  for  that  file,  so  the 
corresponding  memory  can  be  reused.  The 
coding  style  analyzer  can  be  a  background 
process  that  is  executed  on  demand.  If 
executed  in  the  background,  it  should  have 
small  impact  on  the  throughput  of  individual 
programs . 

The  prefix  and  postfix  checker  will 
be  a  simple  defense  that  takes  a  relatively 
short  time  to  execute.  It  will  also  take  a 
small  amount  of  memory  for  its  code  and  data. 
The  prefix  and  postfix  checker  may  need  to 
retain  information  from  the  files  it  checks, 
such  as  al)  the  prefixes  that  are  contained 
in  more  than  one  file  (or  some  threshold 
number  of  files)  and  lists  of  which  files 
contain  each  prefix.  Even  so,  the  amount  of 
information  to  be  stored  will  be  small.  The 
prefix  and  postfix  checker  can  also  be  a 
background  process  which  is  executed  on 
demand.  Because  of  its  simplicity,  this 
defense  will  have  a  very  small  impact  on  the 
throughput  of  individual  programs. 

Time  of  execution,  amount  of  memory 
required,  and  frequency  of  use  do  not  apply 
when  considering  ROM  devices  because  they  are 
not  software  defenses.  The  main 
consideration  is  the  affect  that  ROM's  have 
on  the  execution  of  individual  programs.  The 
affect  of  using  ROMs  will  vary  depending  on 
the  system  and  the  devices  used.  Some  ROM's 
will  be  slower  than  the  corresponding  random 
access  memory  (RAM)  and  some  will  be  faster. 
In  the  case  of  an  IBM  PC  or  XT,  a  ROM  would 
improve  performance  because  its  programs  do 
not  need  to  be  loaded  off  of  a  uisk  as  do 
programs  using  RAM. 

The  intrusion  detector  will  be  a 
complex  defense  that  will  run  continuously  in 
the  background,  keeping  track  of  what  is 
going  on  in  the  system  to  determine  if  the 
system  is  under  attack.  The  amount  of  memory 
required  will  be  rather  large,  but  it  will 
vary  depending  on  the  sophistication  of  the 
detector.  This  defense  will  increase  the 
execution  time  cf  individual  programs  more 
than  the  other  examples  due  to  its  complexity 
and  because  it  will  be  continually  monitoring 
the  system. 

F •  Ease  To  Implement 

When  evaluating  virus  defenses,  one 
must  consider  how  easy  it  will  be  to 
implement  each  virus  defense  measure  with 
respect  to  current  technology.  We  can 
classify  defenses  as  being  (1)  easy  to 
implement  with  current  technology,  (2) 
possible  with  current  technology,  (3) 
requiring  much  work  to  implement,  and  (4) 
requiring  innovative  ideas. 

ROM  devices  are  easy  to  implement 
and  are  widely  used  already.  The  prefix  and 
postfix  checker  would  also  be  easy  to 
implement  with  current  technology,  using  a 
simple  comparison  program.  While  it  is 
possible  to  implement  the  coding  style 
analyzer  with  current  technology,  it  is  not  a 
trivial  task.  The  intrusion  detector, 
however,  will  require  innovative  ideas 
because  it  is  not  well  defined  which  actions 
indicate  r.hat  a  system  is  under  a  virus 
attack. 
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CONCLUSION 


This  taxonomy  should  help  those  who  are 
researching  and  developing  virus  defenses. 
They  can  use  this  tool  in  choosing  and 
evaluating  existing  virus  defenses.  A 
systematic  approach  should  help  prevent 
researchers  from  overlooking  significant 
characteristics  of  virus  defenses.  This 
organization  of  virus  defense  measures 
provider  a  foundation  for  designing  new  virus 
defenses. 


APPENDIX  A 

VIRUS  DEFENSE  MATRIX 


This  appendix  shows  a  wide  range  of 
defense  measures  and  how  they  would  fit  into 
the  taxonomy.  The  coding  style  analyzer,  the 
prefix  and  postfix  checker,  ROM  devices,  and 
the  intrusion  detector  defenses  were  chosen 
as  examples  for  this  paper.  The  column 
headings  are  the  categories  of  the  taxonomy 
and  the  row  headings  are  the  defense 
measures.  The  values  in  each  column  are 
explained  in  the  legend  that  immediately 
follows  the  defense  matrix. 
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Appearance/ Behavior 

a  -  Appearance 
b  -  Eehavior 

Prevent ion/ Detect ion 

p  =  Prevention 
d  «■  Detection 

Source/Executable 

s  =  Source 
e  *  Executable 

Required  Protection 

This  column  will  include  pairs,  with 
one  item  from  each  of  these  two  groups: 

Item: 

m  *  Machine 

a  =  Data  objects  (long-term) 
t  -  Temporary  working 
storage 

Type  of  Protection: 

r  ■>  Read 
w  “  Write 
p  =  Physical 

Performance 

This  column  rates  four  areas  that 
affect  performance.  The  first  element  of 
each  item  is  a  letter  representing  one  of 
these  areas  as  follows: 

t  =  Time  required  to  execute  the 
defense  program  once, 
m  =  Amount  of  primary  memory 
used  for  defense  program 
code  and  data, 

f  =  Frequency  of  execution  of 
the  defense. 

1  =  Affect  on  throughput  of 
individual  program 

execution. 

Numbers  are  associated  with  the 
letters  t,  s,  and  i  in  this  column,  and  they 
give  a  relative  measure  of  the  affect  each 
defense  will  have  on  each  aspect  of 

performance  of  the  system,  on  a  scale  of  o  to 
5.  The  larger  the  number  in  the  column,  the 
greater  the  impact  on  that  aspect  of 

performance. 

The  frequency  of  execution  is 
handled  separately.  The  letters  paired  with 
the  f  for  frequency  are  as  follows: 

i  «*  Interrupt  driven;  only 
called  when  a  suspicious 
event  occurs. 

d  =  On  Demand;  done  in  the 
background . 

c  ■=  Continuously  in  the 
background , 

e  ■  When  protected  programs  are 
executed. 
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Ease  to  Implement 

The  numbers  in  this  column  specify  how 
easy  it  will  be  to  implement  each  virus 
defense  measure  with  respect  to  current 
technology- 

1  ■=  Easy  to  implement  with  current 

technology. 

2  Possible  with  current 
technology. 

3  -  Requiring  much  work  to 

implement . 

4  «■  Requiring  innovative  ideas. 


Brief.  Description  of  Virus  Defenses 


I.  ATTRIBUTES  OF  CHANGE 

These  defense  measures  monitor  programs 
to  see  if  they  have  been  modified.  The 
appropriate  authority  should  designate  which 
files  to  monitor. 

1.  Message  of  Modification  -  This 
defense  is  a  modification  to  an  operating 
system  that  sends  a  message  to  the  system 
Security  Officer's  screen,  or  to  an  audit 
file,  whenever  a  protected  file  is  modified. 


2.  second  Copy  &  Compare  -  This 
defense  can  be  divided  into  two  parts: 
installation  and  comparison.  The 

installation  involves  storing  the  second  copy 
of  all  the  files  that  are  to  be  monitored. 
The  comparison  compares  the  current  copy  and 
the  stored  second  copy  to  see  if  any  files 
have  been  modified.  The  comparison  can  be 
done  as  a  background  process  on  demand. 

3 ■  Selected  Portions  of  Programs- 
This  defense  is  similar  to  the  second  copy 
and  compare  defense  and  can  be  divided  into 
installation  and  comparison.  This  defense 
installs  files  to  be  monitored  by  using  an 
algorithm  to  select  portions  of  these 
programs  and  then  storing  these  selected 
portions.  To  check  to  see  if  the  programs 
have  been  modified,  the  defense  will  apply 
the  algorithm  again  and  make  sure  that  it 
gives  the  same  selected  portions  that  it 
stored  earlier.  This  comparison  can  be  done 
as  a  background  process  on  demand. 

4.  Length  of  Program  -  This  defense 
computes  and  stores  the  length  of  the  files 
to  be  monitored.  It  chf  ks  for  modification 
by  recomputing  the  length  and  comparing  it  to 
the  stored  length. 

5.  nate/Tima  Stamp  -  This  defense 
stores  the  date  and  time  that  each  monitored 
file  was  last  officially  modified.  Each 
monitored  file  will  have  a  data/time  stamp  in 
its  header  that  indicates  the  last  time  it 
was  modified.  The  defense  mechanism  will 
check  to  make  sure  the  stored  time  and  date 
match  the  stamp  in  the  header  of  each  file. 
This  defense  measure  assumes  that  the  system 
will  protect  the  headers  of  files  from  being 
modified  by  any  program  that  is  not 
authorized  to  do  so.  The  virus  may  have 
access  that  allows  it  to  modify  a  program. 


but  most  systems  put  a  greater  restriction  on 
who  is  allowed  to  modify  a  header  to  a 
program. 

6.  Checksum  -  This  defense  computes 
and  stores  a  checksum  for  each  file  that  is 
monitored.  To  check  to  see  if  the  files  have 
been  modified,  the  defense  will  recompute  the 
checksum  for  each  file  and  compare  it  with 
the  stored  checksum. 

7.  Encryption  -  This  defense 
encrypts  the  files  that  are  to  bo  protected. 
Prior  to  execution  those  files  will  be 
decrypted.  If  a  virus  tries  to  write  to  an 
encrypted  file,  the  result  will  be  garbage. 

II .  VIRUS  FINDERS 

These  defenses  can  recognize  a  virus  by 
its  appearance. 

l  ■  ErM  il? _ and  Postfix  Checker- 

This  defense  compares  the  beginning  and  end 
of  files  to  see  if  a  group  of  files  have  the 
same  beginning  or  the  same  end.  A  group  of 
files  with  identical  prefixes  or  postfixes 
are  likely  to  contain  a  virus. 

2 .  Pattern  Matcher  -  The  pattern 
matcher  will  look  for  matching  byte  patterns 
in  groups  of  files.  Since  viruses  are  likely 
to  propagate  by  writing  copies  of  themselves, 
identical  byte  patterns  may  indicate  the 
presence  of  a  virus. 

3 ■  Coding  Style  Analyzer  -  A  coding 
style  analyzer  determines  the  distinctive 
techniques  used  by  each  person  who 
contributed  to  a  program.  If  the  analyzer 
indicates  that  a  given  program  has  more 
programmers  that  it  should  have,  this  may  be 
the  result  of  a  virus.  If  several  otherwise 
unrelated  programs  have  the  same  programmer 
for  part  of  their  code,  this  could  also 
indicate  the  presence  of  a  virus. 

4 .  "Antibiotic"  Program  -  This 
defense  will  recognize  a  virus  based  on  the 
types  of  instructions  it  will  need  for 
propagation,  triggering,  and  performing  its 
mission. 

III.  EXECUTION  LIMITATIONS 

These  defenses  will  prevent  or  detect 
viruses  during  program  execution. 

1 •  Access  Control  Mechanisms- 
Access  control  mechanisms  allow  users  to 
decide  who  is  allowed  to  access  each  of  their 
files  and  what  kind  of  access  they  will  allow 
to  others.  A  virus  can  only  use  the  accesses 
of  its  host  program.  Access  control 
mechanisms  can  slow  viruses  but  will  not  stop 
most  viruses. [3] 

2.  Limited  Domains  --  This  type  of 
defense  limits  the  objects  that  each  u;.er  has 
access  to. 

a.  User-definable  Domains- 
With  this  measure,  each  user  decides  what 
objects  he  will  need  to  access.  He  will 
restrict  himself  to  only  that  set  of  objects 
(called  a  domain)  which  he  will  need. [6) 
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b.  Type/Domain  -  For  this 
defense,  a  domain  is  a  group  of  programs.  To 
access  a  given  typo  of  object,  a  subject  must 
be  part  of  a  domain  that  is  allowod  access  to 
that  type  of  object. [2] 

3.  Lowrleve] _ Minus  One  -  This 

defense  uses  the  Doll  and  LaPadula  model. [1] 
To  protect  a  set  of  executable  programs, 
assign  them  to  a  level  that  is  below  the 
lowest,  level  of  all  the  other  objects  in  the 
system.  If  the  simple  security  property  and 
the 

*-property  are  enforced,  these  low-level 
minus  one  programs  could  be  read  by  all 
subjects,  but  they  could  not  be  written  to  by 
any  subjects  at  the  higher  levels. 

4 .  ROM  Devices  -  Another  way  to 
protect  programs  from  infection  is  to  store 
them  in  ROM's. 

5.  Flow  Distance  -  The  flow 
distance  defense  will  limit  how  far 
information  can  flow  in  a  system.  Each  file 
in  the  system  is  assigned  a  flow  distance 
based  on  how  far  the  data  in  that  file  has 
travelled.  For  example,  if  a  user  writes  a 
program  that  does  not  accept  any  input  data, 
then  that  program  has  flow  distance  of  zero 
while  it  is  in  the  originator's  possession. 
If  the  programmer  gives  this  program  to 
someone  else,  then  its  flow  distance  is 
increased  by  1.  The  flow  distance  of  a 
program  that  accepts  input  data  will  be 
increased  by  the  flow  distance  of  the  input 
data.  The  system  can  limit  the  spread  of 
viruses  by  restricting  the  flow  distance  cf 
data.  If  a  file  receives  a  flow  distance 
that  exceeds  the  maximum,  then  that  file  can 
no  longer  be  used. [3] 

G.  Flow  List  -  The  flow  list 
defense  maintains  a  list  of  each  object  that 
indicates  which  users  have  accessed  that 
object.  The.  system  can  then  prevent  an 
object  from  being  accessed  if  too  many  users 
have  accessed  the  object  or  if  some 
undesirabls  combination  of  users  have 
accessed  the  object.  This  defense  could  also 
be  used  on  the  individual  level  so  that  a 
user  would  only  accept  objects  whose  flow 
list  contains  only  users  that  he  trusts. [3] 

7 .  Intrusion  Detector  -  This 
defense  looks  for  suspicious  behavior  that 
might  be  indicative  of  a  virus  or  some  other 
intrusion . 


Propagation  -  A  computer  virus  propagates  or 
infects  by  writing  a  copy  of  itself 
in  another  program  when  the  virus  is 
executed. [ 5] 
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APPENDIX  B 
DEFINITIONS 


Computer  virus  -  A  computer  virus  is  code 

that  resides  in  a  program  that  can 
copy  itself  onto  other  programs. 
Computer  viruses  have  the  potential 
to  do  great  damage  to  computer 
systems  by  propagating  and  later 
performing  devious  acts  such  as 
deleting  files. [3,  5] 

Host  Program  -  A  program  that  contains  a 
virus. [5] 
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AOs  t  r  act 

This  paper  will  show  that  a  computer 
virus  ICOllEN]  may  be  no  more  a  threat  to 
computer  systems  than  a  Trojan  Horse  and  any 
protection  mechjni  sm  that  will  wt>r  k  against 
a  Trojan  Horse  will  also  work  against  a 
computer  virus.  specifically  a  mandatory 
policy  (e.g  .  | BEIL / LAP  1  [ B I  BA ]  )  In 

add  i  t  i  on  .  it  will  d i scuss  two  poss i b I e 
protection  mechanisms  that  address  the 
Trojan  Hor  se  threat. 


Bac  k  g  r  ound 

A  computer  virus  is  a  program  that 

propagates  itself  ICOHLN)  Depending  upon 
its  design  a  virus  may  propagate  itself  on 
a  limited  basis  or  mo  re  extensively  thiough 
the  file  syst  ern  That  is.  it  nuy 

selectively  propagate  itself  so  that  only 

one  copy  exists  at  any  one  t ime  in  the 
system  [THOMPSON],  it  may  slowly  spread 
through  the  system  or  it  may  propagate  as 
fast  and  as  often  as  possible  in  the  syst  cm 

A  virus  may  act  as  a  Trojan  Horse 

| ANDERSON]  (hereafter  referred  to  as  a 
viritic  Trojan  Horse)  by  performing  an 
overt  action  (the  advertised  purpose  of  the 
code  that  the  executor  expects  to  occur)  a 
covert  action  (typically  benefiting  the 
author  and  harming  the  executor  of  the 
Trojan  Horse,  which  the  executor  does  not 
expect  to  occur)  and  then  propagate  itself 
tc  other  areas  in  the  file  system  taking 
advantage  of  the  executor's  privileges  and 
rights.  Because  a  viritic  Trojan  Horse  can 
'flow  through'  the  system  (via  the  viritic 
feature)  it  may  increase  the  likelihood  of 
execution  and  number  of  executions. 

D.  J.  Edwards  identified  the  Trojan 
Horse  attack  in  [ANDERSON],  In  |KARGLR|. 
the  concept  of  a  Trojan  Horse  propagating 
itself  was  discussed,  although  there  was  no 
distinction  made  between  a  Trojan  Horse  that 
was  viritic  or  not.  The  ARPANET  collapse  on 
October  27.  1980  was  attributed  to  the 

accidental  piopagatior.  of  a  virus  INI  UMANN )  . 
There  are  even  references  to  viruses  in 
modern  science  -f i ct ion  novels  (BRUNNLR]. 


Part  I  Conments  on  Recent  Research 
1  Measuring  Infection  T  nnes 

To  s how  that  a  viritic  Trojan  Horst  was  a 
Significant  threat  beyond  a  r.on  viritic 
Trojan  Horse,  it  would  be  necessary  to 
compare  the  infection  t  inie  ICOHLN]  of  a 
viritic  Trojan  Horse  against  a  comparable 


non  v i r i t  c  Trojan  Horse.  The  use  of  a 
control  group  should  adaquately  show  if  the 
viritic  attribute  will  have  an  additional 
significant  affect  on  the  Trojan  Horse 
thi eat . 

This  author  welcomes  any  research  in  this 
area  For  .  if  done  pr  oper  I y .  i t  wi I  I  show  a 
viritic  Trojan  Horse  to  be  either  a  more 
serious  threat  than  a  non  viritic  Trojan 
Horse  or  of  no  greater  consequence. 

However,  highly  variable  factors  that  will 
c  liange  ovei  the  life  of  the  experiment 
include  "the  enticement"  (this  includes  the 
advertised  overt  capability  of  the  program 
as  well  as  the  met  hods  used  to  sell'  it  to 
the  target  user  conmunity)  to  execute  the 
Trojan  Horse  and  the  knowledge  ot  the  user 
conmunity.  as  well  as  other  sorted  variables 
Such  as  user  activity  level,  t  irue  of  day 
etc.  Researchers  doing  work  in  this  area 
should  be  scrutinized  fully  when  presenting 
results  hppfl  it  5  f>  r>  f  t  h  C  S  G  “field"  vs;  !  s  b  1  c  s 
Therefore.  experiments  must  be  designed  and 
executed  very  carefully  before  any  results 
should  be  considered  credible. 


2  Virus  Affects  on  Systems  with 

Fundamental  Flaws  in  Security  Policies 

[COHEN]  discusses  the  virus  experiments 
that  show  fundamental  flaws  in  security 
po I  i c  i  e  S  "  .  Any  f  undamen  t a  I  f  I  aw  found  in  a 

security  policy  need  not  necessarily  use  a 
vi'us  to  display  the  w a  k  n  e  s  s  A 

n.  n-viritic  Trojan  Horse  should  succeed  in 
demonstrating  any  weakness  sufficiently 
There  is  no  perceived  advantage  in  using  a 
viritic  Trojan  Horse  (as  opposed  to  a 
non  vii itic  Trojan  Horse)  to  demonstrate  a 
f I  aw  in  a  security  po I  icy. 

Although  it  may  be  easier,  in  some  rases, 
to  achieve  a  particular  objective  by  using  a 
viritic  Trojan  Horse,  it  lias  not  tieen  s hown 
nor  does  this  author  believe  that  it  can  be 
s  hown  that  there  is  an  ob  jectivc  a  viritic 

Trojan  Horse  can  achieve  that  a  non  viritic 
Trojan  Horse  can  not  achieve  on  currently 
used  conyiuter  systems 

It  IS  also  interesting  to  note  that  the 
experiments  performed  [COHLN]  were  executed 
on  systems  that  either  did  not  have  an 
enfor  ced  manria tory  security  po I  icy"  at  all 
(i  e..  UNIX.  VM/370  VMS  Tops  20)  or  had 
only  a  partial  implementation  of  a  mandatory 
secur  i  t  y  policy  (  i  e  OS  M  100  On  t  ne  Un i vac 
1108)  |LLE],  thereby  proving  the  obvious 
The  foil ow ing  discussion  will  describe  the 
affects  a  T'ojan  Horse  can  have  on  a  system 


that  enforces  a  mandatory  policy. 


Trojan  Horse  vs.  a  Mandatory  Pol  icy 

The  model  described  by  ( BELL / LAP ] 
protects  systems  against  unauthorized 
disclosure  as  defined  in  a  specific  policy. 
A  Trojan  horse  would  have  to  take  advantage 
of  a  covert  channel  to  disclose  information 
(in  a  properly  implemented  IBELI./LAP) 
s  y  s  t  em )  .  The  s ame  holds  true  for  a  viritic 
Trojan  Horse.  Earlier  work  [COHEN]  made  the 
implication  that  the  Univac  1108  fully 
implements  the  IBELL/LAP]  model  This  is 
not  the  case.  OS /II 00 .  as  delivered  by  the 
vendor,  has  the  concept  of  "security  levels" 
and  enforces  the  s imp  I e- secur i t y  condition, 
but  it  does  not  enforce  the  ‘-property 
[LEE], 

Note:  a  Trojan  Horse  whose  purpose  is  to 
violate  the  integrity  of  a  syst  em  [ B I  BA  J 
could  easily  succeed  in  a  system  that  only 
enforces  the  [BELL/LAP]  model.  Thus,  it  is 
always  true  that  a  system  can  only  protect 
what  it  is  designed  to  protect  and  not 
necessarily  more. 

A  system  that  enforces  an  integrity  model 
| B I  BA]  would  protect  against  a  Trojan  Horse 
(viritic  or  not)  that  attempts  to  violate 
the  integrity  po  I  i  cy  In  ( COHEN  ]  a  r. 
erroneous  conclusion  that  a  system  with  both 
an  integrity  policy  [BIBA]  and  security- 
policy  [BELL/LAP]  must  provide  isolation  was 
arrived.  This  would  be  true  only  if  a 
single  label  were  used  for  both  the  security 
and  integrity  policy  enforcement  (see  Table 
D.  below)  ISCHElL] .  One  must  consider  the 
case  described  in  Table  C.  (i.e..  that  both 
policies  may  exist  concurrently  in  a  system 
without  forming  an  isolation.  01  complete 
partition.  between  security  levels 
( SCHEL  L ]  )  The  foil owi ng  s  imp  I  i  f i ed  ex amp  I e 
illustrates  this: 


Ass  urne  : 

''TS''  and  "U"  are  both  clearances  (on 
users)  and  labels  (on  objects!  that  enforce 
the  security  policy  (  i  . e  .  ,  read  policy). 

'H'  and  "L"  are  both  clearances  (on  users) 
and  labels  (on  objects)  that  enforce  the 
integrity  po I  i Cy  (  i  . e  .  wr  i  t  e  po I  icy)  . 

A  TS'  labeled  object  is  more  sensitive  to 
disclosure  than  a  "U''  labeled  object  A 
"TS  cleared  user  (subject)  is  not  permitted 
to  write  "TS  objects  to  a  "U"  cleared  user 
(subject)  A  "U"  cleared  user  (subject)  is 
not  permitted  to  read  a  "TS"  object. 

An  "H"  labeled  object  is  more  sensitive  to 
modification  and  creation  than  an  "L" 
labeled  object  An  " L  "  cleared  user 
(subject)  is  not  permitted  to  write  an  "H" 
object.  An  "H"  cleared  user  (subject)  is 
not  permitted  to  read  an  "L"  object. 

Access  modes: 


Permissable  actions: 

Ob  j  e  c  t 
I  TS  U 


Subject  TS  I  RA/  R 

I 

U  I  W  RA/ 

I 

Table  A:  Security  policy  (s imp  I  i f i ed  )  . 


As  shown  in  Table  A.  the  basic  concern  is 
to  prevent  an  untrusted  subject  from  reading 
sensitive  objects.  The  flow  of  information 
tends  to  be  from  least  sensitive  to  most 
sens i t i ve  ( "U"  to  "TS"  )  . 


Permissable  actions; 

Object 
I  H  L 


Subject  H  I  RA/  W 

I 

LIP  RW 
I 

Table  B  Integrity  Policy  (simplified). 


In  table  B.  the  basic  concern  is  to 
prevent  an  untrusted  subject  from  wr i t :ng 
(or  creating)  a  high  integrity  object.  Th.e 
flow  of  information  is  from  high  integrity 
to  low  integrity  ( "H"  to  'L). 


Permissable.  actions: 

Object 


! 

TS/H 

TS/L 

U/H 

U/L 

Sub  j  ec  t 

TS/H  1 

RA/ 

W 

K 

Nu  1  1 

T5/L  l 

R 

RA/ 

R 

R 

U/H  1 

W 

W 

RA/ 

W 

U/L  1 

Nu  1  1 

W 

R 

RA/ 

Table  C  * 
i ntegr  i t  y 

Intersect 
po  1  icy. 

0 

c 

o 

bo  t  h  a 

secur 

ty  and 

Table  C  shows  the  relationship  be .ween 
security  and  integrity  It  represents  the 
intersection  of  the  security  and  integrity 
policies  defined  above  A  "U/l-1  subject  can 
neither  Read  nor  Write  on  a  "TS/H  object 
A  "TS/H"  subject  can  neither  Read  nor  Write 
on  a  "U/L  object.  These  are  desirable 
features.  for  they  will  stop  the  fi ow  of  a 
viritic  Trojan  Horse  from  one  partition  fo 
the  next.  wh  ile  still  permitting  the 
controlled  sharing  of  information. 


R  -  Read 
W  =  Wr  i  t  e 
Null  =  None 
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Perrmssable  actions: 

Ob  j  ec  t 
I  TS  U 


Sub  j  ec  t 


TS  I  fW  Null 
I 

U  I  Null  FW 
I 


Table  D:  Sub j ec t / ob jec t  relationship  when 
the  same  label  is  used  for  both  "security" 
decisions  and  "integrity"  decisions. 


Table  D  shows  the  perrmssable  actions 
tl  at  can  occur  on  a  system  where  the  same 
label  is  used  for  both  security  and 
integr  ity  decisions.  The  result  is 
isolation  between  the  two  classes  of  users. 


Surrma  r  y 


Consider  a  file  system  that  has  "n" 
files.  It  would  require: 

n  ( n  +  1  ) 


2 

comparisons  on  the  files  to  completely 
detect  a  successful ly  propagated  Trojan 
Horse  (i.e..  viritic  Trojan  Horse).  If 
during  the  comparison  process,  code  IS  found 
common  iO  two  programs,  they  would  then  be 
considered  suspect.  It  would  be  necessary 
to  "review  by  hand"  to  conf irm  or  deny  the 
presence  of  the  viritic  Trojan  Ho  r  s  e .  The 
code  review  would  point  out  whether  the 
"carmen  code"  has  a  valid  purpose.  \Miat  is 
being  detected  are  similarities  in  code 
that.  in  principle,  should  not  exist.  This 
method  is  independent  of  the  function  of  tha 
(viritic)  Trojan  Horse  That  is.  it  does 
not  matter  what  the  purpose  of  the  viritic 
Trojan  Horse  would  be  to  detect  its 
ex i s  t  ence . 


An  enforced  disclosure  and  Integrity 
policy  can  provide  an  effective  means  of 
stopping  several  classes  of  Trojan  Horse 
(both  viritic  and  non-viritic)  attacks, 
provided  the  mechanisms  are  defined  in 
consideration  of  each  other.  These  policies 
w i  I  I  not  have  an  affect  on  attacks  that 
invoke  Denial  of  Service  problems  on  a 
system.  as  the  disclosure  and  integrity 
policies  mentioned  do  not  address 
Den  i  a  I -of -Se r v i ce  issues. 


While  trie  above  Simplified  uxan  pie 
demonstrates  the  correctness  of  the 
approach,  by  allowing  one  catagory  to  be 
added  to  both  the  security  and  integrity 
labels  each.  the  complexity  of  the  access 
matrix  increases  to  266  different  access 
cases  (15x16).  Although  this  may  appear 
o ve rwhe Iming.  the  defi ned  po licies  can  still 
be  easily  enforced.  no  matter  how  many 
levels  and  how  large  the  catagory  sets  are 
defined  for  both  the  security  and  integrity 
po I  i c  i  es  . 


There  are  systems  available  today  that 
enforce  a  mandatory  pol icy  (MULTICSj 
[ SCOMP ) .  These  systems  will  be  able  to 
provide  protection  against  Trojan  Horse 
(viritic  or  not)  attacks  that  attempt  to 
violate  the  enforced  mandatory  policy. 


Part  II:  Possible  Methods  to  Defeat  Viritic 
Trojan  Horses 

1  .  Compar i son  Utility 

Without  considering  the  objective  of  the 
Trojan  Horse.  it  appears  much  easier  to 
detect  the  presence  of  a  viritic  Troj  n 
Horse  that  has  successfully  propagated 
itself  (i.e.,  more  than  one  copy  of  the 
virus  exists  in  the  system),  than  it  would  a 
non  -  viritic  Trojan  Horse.  This  proposed 
detection  method  would  use  a  conparsion 
utility  to  s  how  the  use  of  similiar  code  i  n 
different  files.  Any  similiar  code 

discovered  may  or  may  not  be  for  legitimate 
reasons . 


This  method  could  not  be  used  to  detect  a 
non-viritic  Trojan  Horse  for  obvious  reasons 
(i.e..  only  one  copy  of  the  Trojan  Horse  may 
exist.  not  several  as  is  likely,  but  not 
necessary  | THOMPSON]  with  a  viritic  Trojan 
Ho  run) 

Given  the  above  possible  solution  to 
detecting  a  viritic  Trojan  Horse,  several 
details  remain.  Detection  depends  upon  ho>w 
good  t  he  compar i son  utility  is.  It  also 
depends  upon  how  well  the  viritic  Trojan 
Horse  succeeds  in  linpianting  its  'uni  id' 
into  innocuous  programs. 

For  a  viritic  Trojan  Horse  to  implant 
itself  successfully.  It  would  have  to  be 
implanted  in  such  a  way  as  to  guarantee: 

a)  that  the  target  program  would  remain 
ope  r a  t  i  ve  ,  and 

b)  that  the  virus  would  be  put  into  a 
location  such  that  the  (entire)  viritic 
aspect  would  be  guaranteed  to  be  executed. 

If  either  of  the  two  preceeding 
conditions  were  not  met.  the  success  of  the 
viritic  Trojan  Horse  would  be  jeopardized 

One  way  to  defeat  the  above  detection 
would  be  for  the  viritic  Trojan  Horse  to 
propagate  itself  such  that  the  child's 
"likeness"  was  not  the  same  as  the  parent’s 
"likeness"  (i.e.,  the  code  appeared 
different  enough  such  that  the  comparision 
utility  could  not  detect  the  similarity). 
This  is  perceived  as  a  difficult,  although 
not  impossible,  problem. 


2.  Spawning  an  Untrusted  Process 

By  enforcing  the  I  ea s t  -  p r  i  v i  I  eged  concept 
on  a  process  by  process  basis.  it  is 
possible  to  provide  a  safe  environment  to 
execute  untrusted  code  (which  may  contain  a 
Trojan  Horse)  (DOANS). 
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Wien  a  process  wants  to  execute 
"untrusted"  code  (which  the  executor 
suspects  contains  either  a  viritic  or 
non-vi r i ti c  Trojan  Horse),  the  process  could 
then  spawn  a  chi  Id  process,  v/nch  would 
include  any  necessary  data.  As  long  as  the 
child's  process  access  rights  are  limited 
with  respect  to  the  parent's  process  access 
rights,  the  parent  process  (and  all 
associated  data  files)  wou  M  be  safe  Of 
course,  anything  in  the  system  that  the 
chi  id  process  can  access  is  a  potential 
victim  to  the  Trojan  Horse,  including  other 
information  located  in  the  child's  process 
(eg  ,  data  deemed  necessary  to  execute  the 
untrusted  code)  and  the  results  of  the 
executed  program. 

If  one  considers  the  child  process  to  be 
t empor  ary  ( i  ,  e  .  ,  for  the  life  of  execution 
of  the  entrusted  program)  and  the  user  can 
terminate  the  progr am  at  will,  then  the  user 
wi  I  I  be  able  to  protect  the  information 
managed  by  the  parent  process,  which  is  the 
goal  of  this  exercise. 

This  can  be  considered  analogous  to  what 
a  system  administrator  can  do  today.  If  an 
administrator  (with  the  appropriate  system 
privileges)  wanted  to  execute  untrusted  code 
(e.g..  a  game  program)  he  could  perform  the 
foil  owl  ng : 

a)  set  up  an  account,  such  that  the  new 
account  had  no  access  to  the  administrator's 
privileged  account  or  access  to  anything  but 
publicly  readable  files. 

b)  login  to  the  new  unprivileged  account. 

c)  execute  the  game  program 

d)  delete  the  unprivileged  account. 

Of  course,  if  the  unprivi I eged  account 
had  write  access  to  any  file  in  the  system, 
the  untrusted  code  (e.g.,  game  program) 
could  propagate  a  viritic  Trojan  Horse  into 
the  unprotected  file,  and  thus  be  subject  to 
further  execution. 

This  is  in  addition  to  the  obvious  risk 
of  unintentional  disclosure,  modification, 
or  deletion  of  any  data  given  to  the  game 
progr  am  to  a  c  c  omp lish  its  task.  (This  risk 
would  be  nonexistent  if  the  untrusted  code 
did  not  need  any  user  supp I  i ed  data.  ) 

The  r  ema i n i ng  p  r  ob I  em  with  this  sccnerio. 
then  is  that  the  untrusted  code  could 
invoke  a  Den  i  g.  I  -of  -Serv  i  ce  attack  on  both 
the  user's  process  and  the  system  Since  a 
we  I  I  accepted  model  is  lacking  in  this  area, 
no  solution  is  proposed. 


Cone  I  us  ion 

A  viritic  Trojan  Ho  r  se  (  i  . e .  .  compu  t  e  r 
virus)  presents  no  new  threat  to  computer 
systems.  If  the  Trojan  Horse  problem  were 
solved  (for  any  class  of  Trojan  Horse 
problems).  the  viritic  Trojan  Horse  problem 
would  also  be  solved  (for  that  same  class). 
Any  solution  to  the  Trojan  Horse  problem 
would  also  be  a  solution  to  the  viritic 
Trojan  Horse  problem. 


A  security  policy  and  an  integrity  policy 
(used  in  conjunction.  in  an  intelligent 
manner)  provide  a  reasonable  protection 
s c h erne  against  Trojan  Horse  (either  viritic 
or  not)  attacks.  A  Trojan  Horse  (viritic  or 
not!  may  still  invoke  a  Den i a  I -of -Ser v i ce 
problem.  unless  a  model  addressing  this 
issue  can  be  st-  ted  and  enforced  in  a 
sys  tern. 

While  a  vir  ic  Trojan  Horse  is 
interesting.  in  t  ■■  fact  that  it  presents 
many  novel  attacks,  it  is  no  more  dangerous 
than  a  non-vintic  Trojan  Horse  attack.  The 
viritic  aspect  of  a  Trojan  Horse  appears  to 
be  more  of  a  red-herring,  in  the  sense  that 
it  nas  taken  attention  from  the  basic 
n  r  oh  I  prrj 

Two  partial  solutions  have  been 
discussed.  Each  must  be  explored  and 
experimented  with  in  more  detail.  Better 
solutions  for  more  classes  of  Trojan  Horse 
attacks  need  to  be  advanced. 
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Abstract: 

Computer  security  is  sometimes  best  served  by 
corking  up  known  holes  in  a  system,  and  sometimes 
by  tracking  an  intruder  to  the  source.  Techniques 
used  to  pursue  the  latter  course  include  high  speed 
network  traces,  operating  system  alarms,  off-line 
monitoring,  and  traffic  analysis.  But  technical 
methods  are  not  enough.  It's  just  as  important  to 
coordinate  efforts  with  law  enforcement  agencies 
and  other  professional  organizations,  and  to 
understand  the  constraints  set  on  each 
organization.  Persistent  sleuthing  can  ultimately 
locate  the  source,  but  it  may  require  considerable 
time  and  effort. 


Introduction: 

When  you  know  a  computer  system  is  under  attack, 
you're  presented  with  a  choice:  should  the  draw¬ 
bridge  be  raised  and  outside  access  cut  off,  or 
should  the  source  of  the  attacks  be  determined? 

This  paper  addresses  what  to  do  when  you  choose 
to  track  the  penetration.  Related  topics,  such  as 
how'  to  detect  an  attack,  or  how  to  protect  a  system, 
are  largely  ignored  here,  although  all  of  these  top¬ 
ics  are  intimately  intertwined. 

Once  you  decide  to  find  the  origin  of  the  attacks, 
you  must  start  a  traceback  effort.  Occasionally,  this 
will  be  easy,  and  the  suspected  intruder  collared 
quickly.  Usually,  the  intruder  will  have  taken  steps 
to  conceal  the  pathway  into  your  system  (often  us¬ 
ing  stolen  resources  to  do  so),  and  unwinding  the 
connections  may  challenge  your  best  efforts. 

Tracebacks  through  digital  and  analog  networks 
are  theoretically  straightforward  --  after  all,  an 
outside  attacker  made  a  physical  connection  into 
your  computer.  In  practice,  however,  unwinding  a 
complex  connection  can  be  quite  daunting,  espe¬ 
cially  in  a  short  time. 


Making  a  traceback  is  essential  for  the  prosecution 
of  an  attacker;  it  also  teaches  lessons  in  network 
connectivity,  coordination  between  law-enforce¬ 
ment  agencies,  and  the  strengths  and  weaknesses 
of  our  interlinked  digital  networks. 

Our  problem,  then,  is  to  unwind  the  connections 
made  by  an  unknown  intruder,  and  ultimately  de¬ 
termine  who’s  in  the  system.  This  effort  requires  a 
thorough  understanding  of  operating  systems, 
networks,  telephony,  and  digital  communications. 
Familiarity  wnth  legal  issues  and  law  enforcement 
protocols  will  be  helpful.  Fitting  together  diverse 
clues,  some  of  which  are  misleading,  eventually 
may  lead  to  an  answer,  although  a  prosecution  may 
not  necessarily  follow. 

Should  you  ignore  the  attack? 

There  are  good  reasons  not  to  try  to  catch  an  at¬ 
tacker.  You  may  subject  your  system  to  danger  - 
the  intruder  may  gain  sufficient  privileges  to  delete 
or  modify  important  files'.  You  risk  the  disclosure 
of  sensitive  information.  It  may  prove  to  be  a  wild 
goose  chase.  The  attacker  might  be  illusory  —  a 
figment  of  your  operating  system.  As  we  shail  see, 
unwinding  a  complex  connectivity  can  become  ex¬ 
pensive,  requiring  coordinated  efforts  of  several 
technicians.  Prosecution  may  prove  impossible,  due 
to  legal  problems,  or  infeasible,  due  to  political  or 
economic  factors.  You  may  embarrass  your 
organization  by  admitting  that  an  outsider  has  ac¬ 
cess  to  your  computers. 

If  you  decide  not  to  trace  the  source  of  an  attack, 
there  are  several  alternatives  available.  You  may 
ignore  the  intrusion  completely.  You  may  close 
your  doors  to  the  attack,  by  changing  passwords, 
tightening  modem  access,  or  strengthening  your 
operating  system.  Or  you  may  simply  legitimize  the 
activity 


*  Perhaps  more  damaging  than  a  massive  deletion  of  files 
is  the  slight  modification  of  files  -  this  may  go  undetected. 
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There  are  also  many  valid  reasons  to  chase  down 
an  attacker.  The  intruder  may  be  out  to  injure  your 
organization,  possibly  for  personal  benefit.  Lost 
resources  can  be  recovered 'only  by  locating 
whoever  took  them.  A  criminal  may  be  caught  and 
prosecuted  by  means  of  a  traceback.  As  a  commu¬ 
nity  service,  tracebacks  of  illegal  activities  help 
make  networks  safer  for  everyone. 

Network  tracebacks  can  be  a  rewarding  area  of 
academic  research.  Trying  to  catch  someone  within 
a  computer  can  lead  you  through  problems  in  oper¬ 
ating  systems,  networking  and  network  topology, 
as  well  as  digital  and  analog  telecommunications. 
Such  work  also  touches  on  technology  law  and  the 
ways  in  which  various  organizations  respond  to 
novel  problems. 


Organizing  your  efforts 

Once  you've  decided  to  trace  an  attacker,  you'll 
need  to  organize  your  efforts.  Early  on,  designate 
one  person  to  serve  as  a  single  point  of  contact  until 
the  problem  is  solved.  Since  your  staff  will  want  to 
know  what's  happened,  stop  rumors  by  holding  a 
meeting 

You'll  need  to  warn  staff  members  to  be  quiet  about 
the  investigation.  If  the  word  leaks  out,  not  only 
will  your  work  have  been  wasted,  but  a  malicious 
intruder  might  damage  your  system.  Law  enforce¬ 
ment  organizations  won't  help  you  if  they  believe 
you  may  leak  investigative  information.  Unless 
your  staff  realizes  the  sensitivity  of  this  matter, 
they  may  mention  it  on  electronic  bulletin  boards,  at 
conferences,  or  to  colleagues. 

Start  a  logbook,  collecting  and  analyzing  your  evi¬ 
dence  within  it.  Record  all  suspicious  activities, 
along  with  their  dates  and  times.  Maintain  a  clear 
distinction  between  conclusions  based  on  firm  evi¬ 
dence  and  suspicions  based  on  indirect  evidence  or 
assumptions.  Summarize  telephone  calls  and  mes¬ 
sages  from  other  sites.  Keep  your  logbook  out  ox 
any  computer  accessible  from  the  system  under  at¬ 
tack  —  assume  that  the  intruder  is  searching  for  it. 

You  will  repeatedly  explain  what  happened  to  a 
variety  of  people,  many  of  whom  won't  understand 
computer  jargon.  For  this  purpose,  prepare  a 
summary  of  what  happened,  using  layman's  terms. 
Describe  exactly  what  damage  has  been  done;  in¬ 
clude  loss  of  services,  disclosure  of  information, 
and  the  costs  to  rebuild  lost  files;  quantify  this 
damage  in  dollars,  if  you  can. 


Keep  records  of  the  costs  of  the  break-in,  and  your 
expenses  in  repairing  it.  This  is  needed  to  deter¬ 
mine  the  level  of  the  offense  (felony  vs.  misde¬ 
meanor);  it  also  indicates  which  agency  will  have 
jurisdiction  over  the  case  (local/state/federal). 
Since  some  expenses  in  tracking  and  solving  the 
problem  can  be  recovered  through  lawsuit,  these 
records  can  be  essential  should  the  case  go  to  trial. 

Many  legal  issues  come  up  in  trying  to  track  and 
prosecute  a  computer  intruder.  What  privacy  rights 
exist?  Can  you  bring  suit  for  damages  against 
someone  breaking  into  your  computer?  Can  you 
recover  for  the  costs  of  tracking?  What  constitutes 
a  breakin?  The  laws  and  interpretations  have 
changed  in  the  past  year,  so  visit  a  law  library  to 
learn  about  current  statutes  involving  computer 
crime.  This  is  especially  helpful  in  communicating 
with  law-enforcement  people,  who  may  not  be 
aware  of  recent  codes1. 

Early  on,  determine  how  deeply  you  are  threat¬ 
ened.  Does  the  attacker  have  system  privileges2? 
Have  Trojan  horses,  logic  bombs,  or  virus  pro¬ 
grams  been  created?  Is  there  a  danger  to  your  sys¬ 
tem  if  you  try  to  catch  the  attacker?  Have  you  the 
resources  to  chase  down  the  attacker?  Set  limits  on 
how  much  time  and  effort  you  will  commit  to  the 
task. 


Who  should  you  tell? 

Soon  after  detecting  an  attack,  you  should  spread 
the  news  to  people  who  can  help  solve  the  problem 
and  to  people  running  other  systems  at  risk.  But 
limit  the  spread  of  this  news!  Certainly,  inform 
your  management  and  your  funding  agency.  If  you 
have  evidence  of  attacks  via  other  systems,  inform 
trusted  system  managers  of  those  sites  by  telephone 
(never  send  computer  security  messages  by  elec¬ 
tronic  mail!). 

Several  external  organizations  may  be  able  to  help 
you.  Your  local  police  are  charged  with  the  en¬ 
forcement  of  local  and  state  laws  -  you  should  be 
in  close  contact  with  them.  Federal  investigation 
and  enforcement  efforts  are  coordinated  through 
the  FBI  and  the  Secret  Service;  the  US  Department 
of  Justice  will  handle  the  prosecution  in  these  cases. 
Problems  which  involve  the  Milnet,  Arpanet,  or 
military  computers  can  be  referred  to  the  Defense 
Communications  Agency  and  the  Air  Force  Office 
of  Special  Investigations. 
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You  should  contact  the  National  Computer 
Security  Center  in  Ft.  Meade;  while  they  perform 
the  difficult  task  of  trying  to  prevent  these 
problems,  they  also  keep  track  of  attacks,  and  can 
coordinate  efforts  to  understand  and  solve  such 
problems.  Additionally,  be  aware  of  the  Institute 
for  Computer  Sciences  within  the  National  Bureau 
of  Standards.  Both  of  these  agencies  can  advise 
you  on  security  holes  which  your  intruder  has  used. 

When  traces  must  be  performed  over  digital  net¬ 
works,  it's  important  to  be  in  close  touch  with  the 
appropriate  network  operations  center.  It's  im¬ 
portant  to  know  beforehand  whom  to  call:  when 
confronted  with  an  attack,  it's  difficult  to  reach  the 
correct  person  quickly. 

Throughout  your  contacts  with  these  organiza¬ 
tions,  keep  records  of  who  you've  spoken  to,  and 
what  response  you've  received.  In  addition  to  re¬ 
inforcing  your  own  memory,  these  records  are 
helpful  in  prodding  agencies  to  take  appropriate 
action. 

Operating  System  Accounting 

Fundamental  to  the  detection  and  tracking  of  any 
unauthorized  computer  user  is  adequate  resource 
accounting.  Modern  operating  systems  typically 
record  resource  usage,  task  names,  times  of  login, 
and  connection  port.  Often,  this  is  the  only  infor¬ 
mation  available  to  determine  the  extent  of  an  in¬ 
trusion3. 

The  quality  of  auditing  data  varies  with  operating 
system,  and  with  the  system  manager's  needs.  With 
good  accounting  data,  and  reasonable  summaries 
of  activity,  audit  trails  are  easily  constructed. 
Spotty  accounting,  with  inaccurate  clock  times  and 
missing  records,  prevent  the  detection  of  even  the 
most  gross  violations. 

Even  if  a  computer  does  not  recharge  for  usage, 
accounting  records  should  be  kept.  Without  these 
audit  records,  it's  impossible  to  reconstruct  what 
has  happened  in  the  past  --  an  essential  part  of 
tracing  an  attacker.  From  this,  it  follows  that  no 
individual  should  be  able  to  disable  accounting.  The 
accounting  records  should,  at  minimum,  include 
port  number  used  to  access  the  computer,  task 
name  executed,  flags  for  attempted  access  to  pro¬ 
tected  files,  and  start /end  times. 

Accounting  records  can  also  be  used  to  identify  the 
incoming  port  and  speed-  If  network  connection 


(e.g.  Milnet  or  Arpanet)  is  indicated,  the  originating 
host  name  may  bo  included  in  the  accounting 
records.  If  the  accounting  records  show  a  serial 
port,  then  determine  the  baud  rate  of  this  port: 
generally,  high  speed  connections  are  from  on-site, 
and  low  speed  connections  are  from  off-site,  usu¬ 
ally  through  modems. 

The  login/logout  times  are  used  as  timestamps  to 
control  searches  into  other  accounting  records. 
These  times  are  compared  to  local  area  netwoTk 
connection  times  or  compared  with  telephone  com¬ 
pany  billing  records.  To  simplify  record  keeping, 
save  these  dates  and  times  in  GMT,  and  keep  your 
clocks  accurate  to  a  second  (non-synchronized 
clocks  confuse  traces  across  several  systems). 

If  no  obvious  damage  is  done,  (perhaps  only  files 
have  been  read),  a  successful  invasion  of  a  comput¬ 
er  may  go  undetected  for  a  long  time.  Thus,  de¬ 
tailed  accounting  records  should  be  saved  for  at 
least  a  year.  These  records  can  be  used  to  show 
how  an  invader  succeeded  in  entering  your  system, 
and  can  point  out  accounts  which  have  been  poi¬ 
soned  by  the  attacker. 

In  some  circumstances,  standard  accounting 
records  may  not  be  trustworthy.  An  invader  may 
have  disabled  accounting  or  modified  accounting 
records.  Accounting  may  be  incomplete  for  some 
nodes  on  your  network.  In  any  case,  ambiguous 
clocks  and  sloppy  record  keeping  will  confuse  the 
interpretation  of  audit  trails. 


Local  Area  Nets 

Almost  every  large  computer  system,  and  many 
smaller  ones,  use  local  area  networks  to  intercon¬ 
nect  terminals,  modems,  computers,  and  other 
networks.  Often  these  are  referred  to  by  the  man¬ 
ufacturer's  name  (Micom,  Develcon,  Sytek,  etc.). 
They  usually  introduce  significant  holes  into  the  se¬ 
curity  of  a  system  —  an  ideal  place  to  plant  Trojan 
horses.  Seldom  are  these  LANs  programmed  by  the 
systems  staff,  or  considered  as  security  problems4; 
they  are  usually  set  up  by  a  communications  group, 
and  then  little  more  than  routine  maintenance  is 
performed.  Few  systems  people  pay  attention  to 
the  connectivity  they  provide”.  A  connection 
through  a  LAN  may  be  impressively  difficult  to 
trace. 

**  For  example,  some  local  area  networks  allow  outside 
dial-in  users  to  immediately  dial  out  from  a  common 
modern  pool,  forcing  the  host  to  pay  for  long  distance 
calls,  and  providing  an  excellent  hiding  place  for  hackers. 
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When  an  attack  originates  from  the  LAN,  it's 
necessary  to  find  the  originating  port.  Usually,  ac¬ 
counting  data  from  the  operating  system  will  tell 
which  computer  port  the  activity  came  in  from. 
Historical  accounting  data  from  the  LAN  controller 
is  needed  to  determine  from  which  port  or  network 
the  attack  originated.  Some  LAN  controllers  simply 
caxmot  provide  this  information  --  avoid  using  such 
systems!  When  this  audit  information  is  available, 
it's  important  to  collect  and  save  the  data  for  later 
analysis.  Make  certain  that  the  connections  are 
recorded  along  with  related  housekeeping  in¬ 
formation,  such  as  baud  rates,  dates,  and  times. 
Since  there  will  likely  be  hundreds  or  thousands  of 
connections  recorded  every  hour,  an  accurate  time 
stamp  is  essential  —  periodically  calibrate  this  clock. 

When  a  local  ethernet  is  suspected  of  being  in  the 
line  of  the  problem,  it  may  be  necessary  to  audit  all 
of  the  connections  on  the  ethernet.  Likely,  this  will 
require  time-domain  reflectometry  to  physically  lo¬ 
cate  all  of  the  drops  on  the  cable.  Because  of  the 
potential  of  promiscuous-mode  listening,  ethernet 
problems  must  be  taken  seriously5. 


Telephone  Traces 

Eventually,  a  telephone  trace  may  be  needed.  For 
many  reasons,  telephone  companies  may  appear  to 
drag  their  heels  before  tracing  a  call.  St's  ofto  r 
technically  difficult,  requiring  skilled  technicians, 
and  phone  companies  may  say  that  they  are  wor¬ 
ried  about  the  risk  of  lawsuits.  Such  statements 
appear  unfounded*;  there  is  no  liability  when  acting 
under  a  search  warrant.  Most  telephone  compa¬ 
nies  ha’"1  departments  which  are  expert  in  tracing 
teleph.  ■ »  lines,  and  telephone  traces  are  common 
procedures. 

A  telephone  trace  can  be  obtained  through  the  ap¬ 
propriate  police  agency,  who  will  contact  the  Dis¬ 
trict  Attorney  for  a  search  warrant.  Affidavits  and 
relevant  evidence  will  be  reviewed  before  the 
courts,  and  a  warrant  issued.  The  telephone  com¬ 
pany  will  probably  need  some  advance  warning 
before  installing  the  necessary  equipment,  or  plac¬ 
ing  technicians  '  standby-  This  calls  for  advance 
cr'"4  .  won  h  .  ,  n  the  computer  site,  the  police, 
and  the  telephone  technicians.  Advance  dry-runs 
will  help  iron  out  problems5. 

+  Such  a  backward  telephone  trace,  (called  a  "trap  and 
trace")  has  been  held  not  to  violate  privacy  rights,  and 
does  not  require  a  order  when  performed  on  your 

own  telephone  line  c  18  U.S.CA  3121  (b)  (1)  and  (b)  (3). 
Indeed,  some  telt  phone  companies  are  now  offering  resi¬ 
dential  service  that  displays  the  originating  telephone 
number  while  the  dialed  phone  is  ringing. 


Depending  on  the  mechanism  used,  telephone 
traces  may  take  place  in  real-time  or  after  the  fact. 
In  either  case,  it  may  be  necessary  to  know  the  exact 
start  time  of  the  incoming  call  to  the  second.  When 
tracing  a  call  through  multiple  exchanges  or 
through  long  distance  exchanges,  simultaneous  co¬ 
ordination  by  several  groups  may  be  required,  since 
traceback  equipment  is  seldom  integrated  with  the 
long  distance  billing  system.  For  real-time  traces, 
telephone  technicians  can  recognise  digital  traffic 
carried  by  its  characteristic  sound  on  a  line,  and  it’s 
usually  straightforward  to  be  certain  that  a  partic¬ 
ular  connection  is  the  valid  one. 

Because  of  deregulation,  interstate  and  cross¬ 
carrier  telephone  traces  can  be  difficult.  Despite 
this,  many  complex  telephone  traces  can  be  done 
within  a  matter  of  minutes,  provided  that  all  orga¬ 
nizations  along  the  line  art  forewarned.  Local  and 
long  distance  telephone  systems  need  automatic 
traces  to  pinpoint  troubles  in  lines  and  switching 
gear,  so  the  equipment  and  techniques  exist. 


After  a  successful  telephone  trace,  a  law-enforce¬ 
ment  agency  may  set  a  pen-register  on  the  tele¬ 
phone  line.  Such  a  device  records  the  phone  num¬ 
bers  of  all  out-dialed  calls**,  and  helps  determine 
tne  extent  of  an  individual  s  telephone  contacts. 


Digital  Network  Traces 


Packet  switched  networks,  such  as  the  Internet, 
have  information  on  the  originating  node  written 
within  the  packet  header  block7.  When  the  network 
links  directly  to  the  host  computer,  packet  informa¬ 
tion  may  be  recorded  by  the  accounting  program. 
Some  networks  convert  the  packets  into  serial  data 
streams  (such  as  RS-232),  and  send  this  stream  to 
the  host;  in  such  cases  the  packet  header  informa¬ 
tion  is  unavailable  to  the  host,  but  may  be  available 
at  the  X.25  interface. 


Packet  header  information  may  be  counterfeit, 
garbled,  or  missing.  When  this  is  suspected,  a  call 
should  immediately  be  made  to  the  network  opera¬ 
tions  center.  Such  organizations  can  quickly  un¬ 
wind  the  linkages  within  their  systems  and  trace  the 
path  of  a  connection.  Such  unwinding  can  only  be 
done  while  the  connection  is  active;  Internet  docs 
not  record  connections  for  later  analysis.  Other 
networks,  such  as  Telenet,  Datapac,  and  Tymnet, 
do  save  records  for  billing  purposes,  and  historical 
connections  can  be  reconstructed,  provided  that 
accurate  times  are  available  for  comparison. 


+  +  The  installation  of  a  pen-register  and  related  recorders 
requires  a  court-order 
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Digital  networks  are  worldwide,  and  some  infor¬ 
mation  may  be  hidden  when  network  boundaries 
are  crossed.  For  this  reason,  international  traces 
require  close  cooperation  between  the  network 
operations  people.  Find  out  in  advance  who  is  re¬ 
sponsible  for  these  traces,  and  exchange  telephone 
numbers.  Know  your  network  location  and  port 
number  as  referenced  by  the  network  —  it  can  save 
several  minutes  in  performing  a  real-time  network 
trace. 

Digital  networks  which  use  datagram  ack/ nak  flow 
control  can  be  timed  to  determine  round  trip  travel 
time.  On  the  Milnet/ Arpanet,  many  seconds  may 
elapse  before  a  datagram  is  acknowledged  on  a 
coast  to  coast  connection.  After  accurately  timing 
these  packet  receipts,  a  statistical  average  will 
indicate  a  nominal  distance  to  the  originating  site. 
A  similar  method  can  be  used  when  Kermit  or 
Xmodem  protocols  are  used  over  serial  lines. 

Some  intruders  will  use  each  successive  computer 
as  a  jumping  off  point  to  get  into  another  system. 
After  stringing  together  several  computers, 
modems,  and  a  variety  of  networks,  such  connec¬ 
tions  may  become  frustratingly  complex. 
Leapfrogging  between  computers  and  networks 
can  allow  an  intruder  essentially  toll-free  access  to 
many  systems,  with  in ior mediate  sites  paying  for 
the  connections.  Fortunately,  interactive  response 
time  suffers,  and  these  users  eventually  simplify 
their  connectivity. 


Alarms  and  Monitors 

When  an  attack  is  suspected,  it's  important  to  de¬ 
termine  exactly  what  information  is  being  sent  out 
of  the  system,  and  what  files  are  being  accessed  by 
the  intruder.  Accounting  information  provides  a 
pointer,  but  there  is  no  substitute  for  a  complete 
printout  of  the  bidirectional  chatter.  This  can  be 
recorded  by  the  operating  system,  but  off-line 
monitoring  is  easier,  better  hidden  and  entails  less 
overhead.  Recording  equipment  (such  as  a  PC  with 
serial  lines  and  a  hard  disk)  can  easily  be  daisy- 
chained*  to  modems,  providing  continual  monitor¬ 
ing  of  all  serial  traffic.  Network  software  (such  as 
the  TCP/IP  daemons)  are  easily  modified  to  save 
traffic,  as  well;  this  can  be  done  on-line  or  off-line. 


The  monitoring  software  and  equipment  can  be 
programmed  to  alarm  whenever  particular  char¬ 
acter  sequences  are  detected.  Thus,  an  alarm  can  be 
set  off  whenever  a  particular  account  is  accessed  or 
whenever  a  certain  password  is  entered.  You  may 
wish  to  build  more  sophisticated  alarms,  using  ex¬ 
pert-systems  techniques. 

When  immediate  response  is  needed,  alarms  can  be 
connected  to  an  auto-dialer**,  to  ring  a  telephone  or 
pocket  pager.  Since  many  intrusions  last  for  only  a 
few  minutes  and  may  occur  at  any  hour,  a  pocket 
pager  is  essential  to  quick  tracing  of  these  calls. 

Operating  system  alarms  usually  warn  the  system 
manager  when  false  logins  have  been  detected,  or 
when  protected  files  have  been  read.  These  are 
very  useful  for  the  detection  of  intruders,  but  can¬ 
not  be  fully  trusted.  When  an  invader  acquires  sys¬ 
tem  privileges,  it’s  likely  that  he  will  disable  ac¬ 
counting,  turn  off  the  alarms,  and  modify  any  files 
that  record  his  presence.  These  on-line  alarms, 
then,  aren't  very  dependable  once  an  attack  has 
succeeded. 


Traffic  analysis 

After  monitors  have  recorded  the  intruder's  traffic, 
analyze  what  has  happened.  Annotate  and  save  all 
printouts;  keep  a  detailed  record  of  what  happened 
in  your  logbook.  Using  the  printouts,  try  to  deter¬ 
mine  what  the  intruder  was  looking  for,  what  he 
tried  to  access,  and  what  keywords  were  impor¬ 
tant.  Did  he  try  to  link  to  another  computer?  What 
passwords  did  he  try?  Did  he  modify  any  of  your 
files?  How  long  did  each  session  last?  What  at¬ 
tracted  his  interest? 

Of  course,  each  intrusion  will  be  different;  detailed 
traffic  analysis  is  crucial  to  the  solution  of  the 
problem,  partly  because  it  describes  the  intruder’s 
interests,  and  in  part  because  it  provides  law-en¬ 
forcement  agencies  with  evidence  useful  in  the 
prosecution  of  the  intruder.  Keep  all  of  these 
records  off  line  —  never  allow  your  security  related 
records  to  be  readable  from  any  computer  network 
or  dial-up  line. 


Hayes-compatible  modems  make  excellent  auto-dialers, 
+  RS-232  data  lines  can  be  multi-dropped  to  drive  several  and  can  be  programmed  to  send  information  to  pocket 
receivers-  pagers. 
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Communications  with  other  sites 

When  an  attack  on  your  site  has  been  detected,  ev¬ 
eryone  wants  to  know  about  it.  It's  necessary  to 
strictly  limit  the  spread  of  this  information  if  you 
wish  to  trace  the  problem.  To  prevent  rumors  from 
spreading,  hold  meetings  to  discuss  progress, 
warning  all  members  that  the  information  should 
not  be  spread.  Talk  openly  with  trusted  site  man¬ 
agers,  but  do  not  leak  information  to  the  press,  or 
to  various  bulletin  boards. 

It's  essential  that  all  communications  be  kept  out  of 
electronic  mail,  and  no  files  be  kept  anywhere  of 
this  activity.  Intruders  will  naturally  scan  file  sys¬ 
tems,  searching  for  keywords  that  might  indicate 
that  they  have  been  detected.  Electronic  mail  is  an 
especially  fmitful  section  to  search. 

When  coordinating  work  with  another  site,  com¬ 
municate  by  telephone.  Keep  any  files  related  to 
this  activity  encrypted.  Assume  that  all  of  your  files 
are  regularly  read  by  the  intruders.  Do  not  keep 
files  with  obvious  names  like  "security"  or 
"hacking”.  When  building  monitoring  programs,  do 
give  away  their  function  with  titles  like  "monitor" 
or  "watchdog". 

Relationships  with  Law  Enforcement  Agencies 

Presently,  the  federal  government  and  several 
states  have  tight  computer  security  laws.  These  are 
enforced  through  the  FBI,  the  Secret  Service,  and 
various  state  and  local  police  agencies.  Police 
training  and  awareness  has  been  recently  in¬ 
creased,  although  most  of  it  seems  to  be  directed 
towards  computer  crimes  with  direct,  measurable 
economic  implications  (e.g.  theft  via  computer,  ac¬ 
cessing  bank  records). 

For  a  poorly  researched  case,  there  isn't  much  hope 
for  enforcement  due  to  the  novelty  of  the  laws,  the 
lack  of  judicial  caselaw,  and  the  need  for  highly 
trained  specialists.  A  well  documented  case,  in¬ 
cluding  a  detailed  analysis  of  the  losses,  will  in¬ 
crease  the  chances  of  police  support. 

Close  cooperation  with  all  levels  of  iaw  enforce¬ 
ment  agencies  is  essential.  You'll  need  to  carefully 
explain  the  nature  of  the  problem,  what  your  losses 
have  been,  and  how  your  problem  relates  to  exist¬ 
ing  laws.  Policies  by  law  enforcement  agencies 
aren't  established  for  these  offenses  and  the  police . 
likely  will  be  hesitant  to  commit  the  resources  to 
open  a  full  investigation.  This  can  sometimes  be 
overcome  by  persistently  explaining  the  need  for 
support,  and  by  doing  as  much  of  the  work  as 
possible  yourself. 


It’s  important  to  communicate  with  the  law  en¬ 
forcement  community  early.  Determining  what 
agency  to  contact  may  be  difficult;  within  any 
organization,  probably  only  one  or  two  people  can 
appreciate  the  nature  of  the  crime  being  committed. 
For  this  reason,  you  may  find  it  fruitful  to  explain 
your  problem  to  all  possible  agencies,  and  allow 
them  to  refer  you  to  the  correct  organization.  Each 
law  enforcement  organization  has  its  own  special¬ 
ties;  don't  assume  that  you'll  necessarily  get  more 
support  from  a  national  agency  —  indeed,  you  may 
find  that  your  local  police  arc  far  more  interested 
and  supportive. 

When  telephone  traces  are  needed,  advance  ar¬ 
rangements  with  your  police  contacts  will  prove 
invaluable:  the  telephone  companies  generally  re¬ 
quire  court-orders,  and  the  police  know  how  to 
work  with  the  appropriate  district  attorney  to  ob¬ 
tain  these.  The  phone  companies,  in  turn,  are 
comfortable  reporting  to  the  police,  but  do  not  wish 
to  report  to  injured  parties,  for  fear  of  lawsuits. 

Conclusion:  Locking  the  Bam  Door 

You  can  trace  connections  back  to  the  source  in 
most  circumstances.  You'll  need  to  keep  detailed 
records,  analyze  audit  trails,  set  monitors,  traps, 
and  alarms,  and  closely  watch  your  operating  sys¬ 
tem.  Actual  line  traces  may  be  in  real-time  or  his¬ 
torical.  Ironically,  there  are  relatively  few  technical 
challenges;  the  main  problems  are  in  coordinating 
the  efforts  of  many  organizations. 

Once  you've  tracked  the  rascal,  finding  out  just 
who's  been  giving  you  such  grief,  you'll  still  have  to 
close  all  the  doors,  whether  or  not  he's  been  prose¬ 
cuted  (or  even  arrested).  You'll  need  to  simultane¬ 
ously  delete  the  accounts  which  have  been  com¬ 
promised,  eliminate  the  security  holes,  and  change 
all  passwords  on  your  systemm.  Pulling  the  plug 
may  be  quite  involved,  and  calls  for  advance 
preparation 

Our  networks  provide  rich  connectivity;  alas,  but 
few  people  are  paying  attention  to  the  risks  which 
are  created.  When  confronted  with  attacks  and 
intrusions,  system  managers  often  talk  about  trac¬ 
ing  the  connections,  but  seldom  actually  initiate 
traces.  With  a  little  perseverance,  it’s  possible  to 
unwind  connections,  and  find  out  who’s  at  the  oth¬ 
er  end.  After  tracing  an  intruder,  tell  your  tale  to 
others  —  let  the  rest  of  the  world  learn  from  your 
sorrows. 

With  hundreds  of  users,  a  complete  password  change 
is  distasteful.  Alas,  but  no  other  method  (password  aging, 
account  expiration,  account  rcqualification)  can  assure  you 
of  a  dean  system,  without  compromised  accounts. 
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ABSTRACT — Malicious  logic  can  be  placed  into  a 
computer  system's  software  in  order  to  deliberately  disrupt 
normal  operation.  Of  particular  concern  is  Us  potential 
effect  on  military  systems.  Two  possible  effects  of 
malicious  logic,  which  are  addressed  in  this  paper,  are 
dcnial-of-service  and  compromising  data  integrity. 
Presented  are  several  ad  hoc,  admittedly  imperfect, 
techniques  that  are  designed  to  reduce  the  risk  posed  by 
malicious  logic.  These  techniques  can  be  used  now,  while 
more  complete  solutions  are  sought. 

1.  INTRODUCTION 

Recently,  several  authors  have  observed  many  similarities 
and  interrelationships  between  fault  tolerance  and  computer 
security  [6,19].  In  fact,  in  [6],  denial-of-service  is  viewed 
as  the  classical  unreliability  problem.  The  main  goal  of  this 
paper  is  to  explore  the  application  of  several  fault  tolerance 
techniques  to  the  elimination  of  the  effects  of  malicious 
logic.  Additionally,  for  a  more  complete  discussion,  a  few 
techniques  from  computer  security  are  also  included. 

As  presented  in  [3],  a  few  definitions  are  essential.  A 
fault  is  a  hypothesized  cause  of  an  incorrect  state  of  some 
system  resource.  An  error  is  the  erroneous  state  of  that 
resource.  A  failure  occurs  when  the  user  of  a  computing 
system  observes  the  system  not  performing  as  was  specified. 

Ttie  application  of  fault  tolerance  techniques  to  the 
problem  of  malicious  logic  is  derived  from  the  observation 
that  its  effects  can  be  classified  under  the  fault  class  of  "by 
intent".  This  class  of  faults  includes  both  accidental  and 
deliberate  faults.  Here,  malicious  logic  are  deliberate 
design  faults  (in  software  or  hardware)  that  cause  errors  in  a 
computing  system  which  may  lead  to  improper  service. 

The  techniques  presented  in  this  paper  are  only  for  highly 
critical  systems.  They  address  the  threat  of  a  trusted 
engineer  inserting  malicious  logic  into  the  computing  system 
he  or  she  is  developing  or  maintaining. 


Ollier  recent  work  addressing  protection  techniques 
against  malicious  logic  appears  in  [5,13,17].  These 
techniques  could  be  used  in  conjunction  with  those  presented 
here.  Definitions,  examples,  and  derivation  of  fundamental 
principles  of  denial-of-service  in  operating  systems  and 
computer  networks  appears  in  [7.8]. 

2.  MULTI  PRONGED  DEFENSE 

Malicious  logic  can  disrupt  a  computer  system's  normal 
operation  from  many  locations  in  its  software  (e.g., 
application  and  operating  system  code).  This  large  search 
space  provides  many  opportunities  and  makes  it  difficult  to 
prevent  or  detect  malicious  logic  Insertion  into  software.  A 
muiti-prongeo  defense,  composed  of  off-ime  and  on-iine 
techniques,  is  proposed  to  reduce  the  risk  posed  by  malicious 
logic.  Off-line  techniques  (e.g.,  verification)  are  directed 
at  preventing  the  insertion  of  malicious  logic  for  the  entire 
life-cycle  of  software.  On-line  techniques  (e.g.,  execution 
monitoring)  attempt  to  counter  the  effects  of  malicious 
logic  that  has  successfully  made  its  way  into  a  deployed 
computer  system. 

Ail  the  on-line  techniques  presented  are  completely 
application  dependent,  whereas  the  off-line  techniques  can 
be  more  general.  The  reason  for  this  lies  in  the  fact  that 
the  on-line  techniques  are  used  in  single  threat  counter¬ 
measure  pairs,  whereas  each  off-line  technique  can  cover 
many  threats. 

Tradeoffs  of  performance  versus  the  degree  of  risk  are 
essential  and  should  be  carried  out  from  the  onset  of  a 
project.  Additionally,  to  determine  the  effectiveness  of  a 
chosen  collection  of  ad  hoc  techniques,  an  error  seeding 
approach  directed  by  penetration  teams  could  be  used.  Each 
of  these  topics  is  examined  in  detail  below. 

3.  PROPERTIES  OF  MALICIOUS  LOGIC 
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Malicious  logic  is  defined  as  deliberate  design  faults 
witli  the  intent  to  commit  ari  unlawful  act  or  cause  harm 


without  legal  justification  or  excuse.  Two  possible  effects 
of  malicious  logic,  which  are  addressed  in  this  paper,  arc 
dcnial-of-service  and  compromising  data  integrity. 

Malicious  logic  is  designed  tc  avoid  detection  by  both 
off-line  and  on-line  techniques.  To  escape  detection  by 
off-line  techniques,  malicious  logic  is  hidden  in  the 
complexity  of  the  system's  software  or  hardware.  Tor 
example,  in  software  this  can  be  done  by  the  use  of  multiple 
levels  of  macro  calls,  and  deliberate  use  of  complex  and 
tricky  coding  practices.  To  hide  from  on-line  techniques, 
malicious  logic  could  try  to  create  errors  which  appear  to  be 
results  of  naturally  occurring  faults. 

4.  ON-UNI-  TECHNIQUES 

On-line  techniques  include  additional  software,  hardware, 
and  partitioning  methods  aimed  at  preventing  the  effects  of 
existing  malicious  logic  in  a  deployed  computer  system.  It 
would  be  useful  if,  during  execution,  these  techniques  could 
also  explicitly  determine  the  location  of  such  logic.  Once 
located,  it  could  then  be  targeted  for  removal  as  soon  as 
possible. 

A.  N-Version  Programming 

N-Version  Programming  (NVP)  can  be  used  to  provide 
reliable  software  [!].  N-versions  of  one  program  are 
independently  designed  and  implemented  from  a  common 
specification  (or  possibly  from  several  independently  written 
specifications).  All  N-versions  are  executed  concurrently, 
typically  on  an  N-proccssor  computer  system.  During 
execution,  the  versions  periodically  vote  on  intermediate 
results  and  on  the  final  result.  As  long  as  a  majority  of 
versions  produce  correct  results,  design  faults  in  one  or 
more  version  will  be  masked  out.  The  strength  of  this 
approach  is  that  reliable  computing  does  not  depend  on  the 
total  absence  of  design  faults. 

Thus,  NVP  can  be  used  to  maintain  the  integrity  of  func¬ 
tion  and  data  by  masking  out  the  incorrect  outputs  of  delib¬ 
erate  design  faults.  The  probability  of  identical  copies  of 
malicious  logic  appearing  in  a  majority  of  the  N-versions  is 
diminished  due  to  the  independent  design  and  implemen¬ 
tation  of  multiple  versions. 

A  topic  of  further  research  is  whether  NV1’  is  effective 
against  denial-of -service  threats.  At  this  time,  the 
following  obseivations  can  be  made.  Instances  of 
dcnial-of-service  threats  which  involve  the  hoarding  of 
system  resources  (e.g.,  CPU  time,  disk  space)  may  be 


prevented  by  NVP.  The  specification's)  of  the  N-verstons 
must  clearly  state  a  set  of  restrictions  that  all  versions 
must  adhere  to.  For  example,  it  can  be  specified  that  a 
version  can  have  only  a  limited  number  of  open  files  and/or 
child  (forked  as  in  UNIX)  processes.  (Each  child  consumes 
CPU  time,  main  memory,  and  disk  space.)  Now,  the  voting 
mechanism  used  in  NVP  can  be  applied  to  a  version's 
actions,  such  as  system  calls  made,  rather  than  to  generated 
data  values  only.  Thus,  if  lers  than  a  majority  of  versions 
try  to  obtain  excess  resources,  the  remaining  versions  will 
prevent  such  hoarding  hy  masking  out  the  resource 
requesting  system  calls. 

A  new  instance  of  the  denial-of-service  threat  may  be 
possible  for  2VP  systems.  Malicious  logic  need  only  be 
placed  in  one  version,  and  would  be  designed  to  deliberately 
cause  the  two  versions  to  disagree.  Typically,  a  majority  of 
versions  is  needed  in  order  to  produce  a  result.  Thus, 
continued  disagreement  could  cause  some  degree  of 
denial-of-service. 

At  least  two  solutions  exist  for  this  new  problem.  The 
above  example  emphasizes  an  important  feature  of  most 
NVP  systems,  that  of  masking.  Only  when  N  is  greater  than 
or  equal  to  three  can  incorrect  actions  be  masked  out. 
Thus,  one  solution  is  to  prohibit  the  use  of  2VP  systems. 

Another  solution  is  to  use  a  hybrid  form  of  NVP  and 
Recovery  Blocks  [1,3J  to  prevent  the  malicious  version  from 
voting  and  forcing  a  disagreement.  This  is  done  by  adding 
trusted  self-checking  code  (i.e.,  the  acceptance  tests  used 
in  Recovery  Blocks  [15])  to  both  versions.  Acceptance  tests 
are  additional  program  statements  which  are  used  to  test 
whether  a  section  of  code  performs  as  it  was  specified. 
Each  time  the  malicious  version  failed  an  internal 
acceptance  test  its  outputs  would  be  ignored,  thus 
preventing  the  denial-of-service.  Such  a  hybrid  form  has 
already  been  shown  to  be  effective  for  handling  accidental 
design  faults  in  NVP  systems  [3], 

it  is  noteworthy  that  NVP  ajjg  addresses  completeness 
which  is  part  of  integrity,  and  timeliness  of  action.  Several 
versions  ensure  through  voting  that  all  specified  actions  are 
performed.  A  timeout  mechanism  on  a  voting  point 
prevents  prolonged  periods  without  action.  Timeliness  of 
access  to  some  specified  computing  system  service  is  an 
important  capability  in  combating  deriial-of-scrviee  threats 

IS) 

Additionally,  the  acceptance  tests  in  the  hybrid  form  of 
NVP  and  Recovery  Blocks  could  attempt  to  distinguish 
deliberate  and  accidental  design  faults.  Thus,  detection  of 


deliberate  design  faults  could  be  used  to  trigger  an  alarm 
notifying  the  appropriate  authorities.  It  appears  that  more 
than  just  masking  out  design  faults  is  needed  if  locating 
deliberate  design  faults  is  also  desired.  It  should  be  made 
clear  that  in  general  all  design  faults  are  important. 
However,  this  discussion  concentrates  only  on  deliberate 
ones- 

NVP  is  application  dependent  in  two  ways.  First, 
determining  how  much,  and  which  parts,  of  a  software 
system  will  be  built  using  NVP  may  be  different  for  each 
application.  Second,  if  used  against  denial-of-service 
threats,  then  restrictions  placed  in  the  specification(s)  will 
likely  be  different  for  many  applications. 

B.  Software  Safety 

Software  safety  techniques  110,111  have  been  applied  to 
safety  critical  systems.  An  entire  system  view  is  taken  in 
applying  these  techniques  (i.e.,  both  computer  and  non¬ 
computer  hardware).  System  conaitions  which  could  lead  to 
unsafe  failures,  called  hazards,  are  hypothesized.  Fault- 
tree  analysis  is  used  to  locate  where,  if  at  all,  in  the 
system's  software  these  series  of  conditions  could  occur. 

Safety  assertions  are  used  to  detect  hazards  and  are  a 
form  of  the  acceptance  test  used  in  Recovery  Blocks. 
Safety  assertions  are  placed  in  the  software  along  with 
recovery  routines  which  are  used  to  restore  a  system  to  a 
safe  operating  or  fail-safe  state.  The  strength  of  this 
method  is  in  the  total  system  view  taken. 

These  techniques  are  a’so  applicable  to  prevent  the 
effects  of  malicious  logic.  A  typical  example  of  denial- 
of-service  is  an  overloaded  use  of  a  system's  processing 
resources  (e.g.,  CPU  time).  Here  the  unsafe  failure  state  is 
denial-of-service,  while  the  hazard  is  the  overloaded 
processing- 

Assume  (for  this  example)  that  fault-tree  analysis 
determines  that  in  the  executive's  scheduler  this  hazardous 
state  could  be  observed.  To  counter  this  threat,  the 
following  safety  assertion  would  be  placed  there: 

assert  underload:  if  utilization  <*  max.limit 
on  failure  do 

assert  diagnosis  1:  [condition] 
assert  diaguosis2:  jeondi:  ion]  od 

When  the  "underload"  assertion  becomes  false,  special 
recovery  routines  will  be  invoked  via  the  'on  failure  do" 
clause.  These  routines  are  application  dependent  and  can  be 
grouped  in  a  safety  executive  as  described  in  [1 1]. 


To  handle  this  possibly  intentional  overload  condition  the 
recovery  routines  would  preempt  running  tasks.  This  should 
continue  until  the  load  on  the  system’s  computing  power 
decreases  to  a  point  where  real  work  can  progress. 

C.  Monitors 

Let  us  consider  a  large  banking  institution’s  transaction 
processing  system  as  a  target  of  malicious  logic.  In  the 
peak  of  business  activity,  the  bank's  computer  network  of 
automated  teller  machines  and  mainframes  is  forced  into  a 
self-test  operational  mode.  These  tests  could  require  such  a 
significant  amount  of  computing  power  that  the  bank's 
computers  are  unable  to  process  any  significant  number  of 
incoming  transactions. 

Ttiis  situation  could  result  in  a  large  financial  lots  to  the 
bank  in  question.  In  fact,  the  bank  could  be  held  for  ransom, 
such  that  its  computers  would  occasionally  be  rendered 
inoperative  unless  a  sum  cf  money  were  paid.  To  counter 
this  particular  threat  and,  possibly,  others  like  it,  a  trusted 
computing  base  (TCB)  can  be  defined  that  mediates  actions 
which  are  meaningful  at  the  application  level  [4,  p.67J. 
Access  to  objects  involves  not  only  reads  and  writes,  but 
how  and  when  application  and  operating  system  functions 
are  invoked.  Here,  programs  are  the  objects,  and  access  to 
them  is  equated  to  their  execution. 

Now,  invocation  of  the  self-test  function  can  be 
accomplished  only  after  the  TCB  scrutinizes  the  request. 
All  such  potentially  damaging  use  of  basic  system  functions 
can  be  placed  behind  this  defined  security  perimeter.  All 
requests  which  are  disallowed  can  then  be  viewed  as  audit- 
able  events.  This  technique  requires  defining  a  different 
security  perimeter  for  each  application.  The  potential  for 
misuse  of  system  functions  is  typically  different  for  each 
application. 

The  concept  of  program  flow  monitors  (PFM)  [18]  can  be 
extended  in  order  to  prevent  incorrect  a-  ons  of  a  program 
on  data  items.  To  do  this,  each  of  the  defined  data  manipu¬ 
lation  functions  (e.g.,  remove  network  packet  header)  is 
given  a  unique  signature;  for  example,  a  sequence  of  bits  in 
a  bit  vector.  Also,  each  data  item  is  initially  given  an 
empty  signature.  The  result  of  a  sequence  of  data  manipu¬ 
lations  is  a  combination  of  all  the  performed  functions' 
signatures  stored  in  the  data  item's  signature. 

For  each  sequence  of  acceptable  data  manipulations.  an 
associated  sequence  of  acceptable  signatures  exists  and  is 
stored  in  the  PFM.  That  is,  one  signature  exits  for  the 
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result  of  each  data  manipulation.  At  the  application  of  a 
data  manipulation  function,  the  PFM  precomputes  what  the 
resultant  signature  will  be  if  the  operation  is  performed. 
This  precomputed,  dynamically  generated  signature  is  tested 
by  the  PFM  to  see  if  it  represents  a  valid  signature.  If  the 
signature  is  not  acceptable,  then  the  data  manipulation  is 
not  performed  and  some  response  depending  on  the  partic¬ 
ular  application  is  necessary  (c.g.,  auditable  event,  drop 
packet). 

To  strengthen  this  approach,  the  number  of  times  that  the 
same  function  is  applied  to  a  data  item  can  also  be  encoded 
in  the  signatures  [12].  An  example  of  where  this  can  be  used 
is  a  network  protocol  function  that  removes  a  packet 
header.  Correctly  functioning  protocol  software  should 
remove  the  header  only  once.  However,  malicious  logic  may 
try  repeatedly  to  remove  the  header  in  order  to  obtain  a 
pacKet's  data.  Assuming  that  tne  protocol  software  is  not 
authorized  for  access  to  the  packet's  data,  such  access 
would  generate  an  invalid  signature. 

Thus,  program  flow  monitors  can  be  used  to  ensure  the 
integrity  of  function  and  data.  This  could  also  be  viewed  as 
just  another  example  of  part  of  a  1C”,  as  mentioned  above. 

5.  OFF-LINE  TECHNIQUES 

Off-line  techniques  are  used  to  remove  malicious  logic 
throughout  the  entire  software  life-cycle  (e.g.,  the  devel¬ 
opment,  testing  and  maintenance  stages  of  a  projec). 
Removal  of  malicious  logic  follows  its  explicit  detection  in 
a  software  system. 

These  techniques  are  applied  to  dll  types  of  software  in  a 
computer  system  (e.g.,  both  operating  system  and  appli¬ 
cation  code).  In  particular,  the  on-line  security  mechanisms 
chosen  to  protect  a  system  from  attacks  are  themselves 
targets  for  malicious  logic  insertion.  The  trust  placed  in 
these  mechanisms  must  be  validated.  This  can  be  done  by 
one  or  some  combination  of  the  following  methods:  fault- 
tree  analysis  as  mentioned  above,  formal  verification,  test¬ 
ing  and  code  reviews. 

A.  The  Use  of  Formal  Verification 

Current  formal  verification  techniques  and  tools  can 
effectively  examine  only  small  pieces  of  software  (e.g.,  a 
security  kernel  in  an  A1  certified  computer  system  [4]).  If 
the  security  mechanisms  used  are  too  large,  then  formal 
verification  can  be  done  on  selected  pieces. 


Tor  NVP,  formal  verification  or  any  validation  method 
should  be  concentrated  on  the  support  software,  since  this  is 
where  malicious  logic  could  have  its  effects.  For  example, 
pans  of  the  DEDIX  [1,2]  (DEsign  Diversity  experiment) 
system  developed  at  the  UCLA  Center  for  Experimental 
Computer  Science  should  be  formally  verified  (e.g.,  the 
voter  logic).  If  each  version  of  the  support  software  was 
itself  from  a  diverse  design,  then  the  importance  of 
verification  could  be  reduced. 

For  software  safety  techniques,  the  safety  assertioas  and 
recovery  routines  are  candidates  for  formal  verification. 
Finally,  the  same  extensive  methods  used  for  TCBs  seem  to 
apply  to  all  types  of  monitors. 

B.  Testing 

Malicious  logic  could  be  designed  to  trigger  on  particular 
state  conditions  (e.g.,  the  date,  or  by  command).  Tne 
trigger  could  also  be  disabled  until  a  command  was  sent 
enabling  it.  This  enabling  command  could  simply  be  a 
sequence  of  legal  but  odd  system  requests  (e.g.,  one  hundred 
health  status  system  requests  in  a  five-minute  time 
interval). 

Standard  testing  methods  would  likely  be  ineffective  in 
locating  such  malicious  iogic,  since  they  would  probably 
miss  enabling  the  triggers.  Therefore,  new  testing 
approaches  aimed  at  detecting  possible  enabling  command 
sequences  (i.e,,  channels)  and  trigger  devices  should  be 
used.  This  requires  a  separate  test  plan  from  the  normal 
functional  testing. 

in  addition,  the  use  of  independent  testing  teams  from 
alternate  contractors  has  been  shown  to  increase  testing 
effectiveness.  Component  testing,  at  the  module  level  by 
the  independent  teams,  also  seems  necessary,  since  testing 
at  only  the  device  level  is  of  insufficient  depth  for  our 
purposes. 

C.  Configuration  Control 

Very  strict  configuration  control  software  and  procedures 
are  essential.  This  will  help  to  ensure  that  malicious  logic  is 
not  added  after  all  tests  are  made  to  ensure  its  absence.  To 
guarantee  that  proper  procedures  are  followed  surprise 
inspections  could  be  used  in  order  to  moni‘  or  the  developer. 

D.  Code  Reviews  for  Malicious  Logic 

It  is  a  straightforward  extension  to  perform  code  reviews 
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specifically  to  discover  malicious  logic.  This  review  process 
should  be  done  by  teams  in  order  to  ensure  its  validity. 
Reviews  are  conducted  during  the  development  process 
rather  than  afterwards  by  penetration  teams. 

These  last  two  techniques  (i.e.,  configuration  control  and 
code  .eviews)  can  go  a  long  way  to  prevent  insertion  of 
malicious  logic  into  a  software  system.  It  is  this  author's 
opinion  that  they  should  always  be  a  part  of  the  selected 
off-line  techniques. 

6.  TRADEOFFS 

It  is  frequently  difficult  to  satisfy  all  the  desired 
objectives  of  a  system  (e.g..  performance,  security,  fault 
tolerance,  compactness,  etc.).  Since  resources  are  always 
limited,  it  is  essential  to  decide  from  the  onset  of  a  project 
the  amount  to  dedicate  to  security  concerns.  Resources  are 
both  computer  resources,  such  as  millions  of  instructions  per 
second,  and  project  resources,  such  as  a  budget  to  perform 
verification. 

To  determine  the  amount  of  resources  to  dedicate,  an 
acceptable  degree  of  risk  from  the  threats  posed  by 
malicious  logic  must  be  defined.  Tradeoffs  should  be 
performed  between  security  and  other  desired  system 
objectives  using  the  acceptable  degree  of  risk  as  a  conttol 
on  the  investment  in  security  mechanisms.  Of  course,  in 
order  to  perform  these  tradeoffs,  some  idea  of  the  costs  and 
effectiveness  of  the  proposed  security  mechanisms  must 
exist. 

Additionally,  an  analysis  of  the  proportion  of  off-line 
versus  on-line  techniques  to  be  used  in  the  total  security 
budget  should  be  performed.  Decisions  of  this  type  can  be 
made  based  on  the  cost,  effectiveness,  and  performance 
impact  of  each  approach.  For  example.  NVP  can  be  very 
expensive  in  development  and  maintenance.  Therefore, 
widespread  use  of  this  technique  in  certain  software  systems 
may  be  unlikely.  Instead,  it  could  be  used  selectively,  as 
determined  from  a  tradeoff  study. 

Obviously,  off-line  techniques  have  the  advantages  or  not 
affecting  performance,  weight,  or  power  (i.e.,  attributes  of 
the  physical  computer  system).  However,  on  large  software 
programs,  their  effectiveness  may  be  too  limited.  This  is 
evident  from  experiences  with  current  formal  verification 
technology. 


7.  MEASURE  OF  EFFECTIVENESS 

Effectiveness  measurements  of  the  collection  of  ad  hoc 
approaches  chosen  can  be  used  in  design  refinement.  If 
serious  protection  problems  are  discovered  during  measure¬ 
ment,  steps  can  be  made  to  compensate. 

To  obtain  this  measure,  deliberate  insertion  of  malicious 
logic  similar  to  the  technique  of  fault  injection  used  in  fault 
tolerance  to  determine  fault  coverage  [18],  and  error 
seeding  techniques  used  in  software  testing  [14),  can  be 
employed.  The  determinations  of  what  malicious  logic  and 
where  to  implant  it  can  be  made  in  several  ways.  First,  use 
a  penetration  team  whose  experience  in  security  concerns 
helps  them  devise  implants.  Second,  test  specific  conditions 
addressed  by  existing  on-line  security  mechanisms.  And 
last,  use  analysis  techniques  such  as  fault-tree  analysis  as 
employed  in  software  safety  [10,1 1]. 

Deliberate  insertion  of  malicious  logic  for  testing 
purposes  obviously  must  be  done  with  great  care.  The 
process  of  implanting  must  be  well  documented  and 
performed  by  a  team.  Implants  should  be  placed  only  in 
experimental  versions  used  solely  for  testing.  These 
versions  should  never  be  placed  in  the  same  configuration 
library  where  the  real  operational  software  is  stored. 

Measurements  of  effectiveness  of  both  on-line  and 
off-line  techniques  can  be  performed.  For  on-line  tech¬ 
niques,  malicious  logic  is  placed  in  operating  software 
during  normal  system  testing.  For  off-line  techniques,  such 
as  formal  verification,  malicious  logic  is  deliberately  placed 
in  preverified  code  during  early  design  stages. 

Performing  such  measurements  requires  defining  what  is 
to  be  measured  (the  metric)  and  how  the  results  ate  to  be 
evaluated  (the  criterion).  The  metric  is  the  percentage  of 
instances,  where  implanted  malicious  logic  goes  undetected 
out  of  the  entire  body  of  tests  [18].  The  criterion  is 
composed  of  two  pares.  First,  it  must  take  into  account  the 
coverage,  or  quality  of  the  error  seeding  cases  [14J.  Second, 
the  calculated  percentage  is  interpreted  relative  to  the 
acceptable  degree  of  risk  defined  in  the  design  phase.  Two 
results  should  be  generated:  one  for  all  on-line,  and  one  for 
all  ofi-line  techniques  used.  This  way.  the  return  on 
investment  of  each  approach  can  be  compared. 

8.  CONCLUSIONS 

The  multi-pronged  defense  presented  is  meant  to  be  a 
practical  and  immediately  usable  approach  to  decrease  the 
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risk  of  malicious  logic  in  critical  computer  systems.  All  the 
techniques  presented  appear  to  be  used  in  specific  threat- 
countermeasure  pairs.  It  may  be  possible  to  strengthen 
these  techniques  by  changing  this  one-to-one  relationship  to 
a  many-to-one  relationship  (i.e.,  one  countermeasure 
covering  many  forms  of  malicious  logic). 

In  approaching  the  difficult  problem  of  preventing 
denial-of-service  and  ensuring  integrity,  new  ad  hoc 
techniques  should  be  devised.  These  new  techniques  should 
be  encouraged  but  still  must  follow  good  security  common 
sense.  For  example,  new  techniques  should  not  depend  on 
trusting  large  portions  of  software.  It  is  beyond  the  current 
state-of-the-art  to  formally  verify  and  validate  trust  in 
large  pieces  of  software.  Also,  such  obvious  weaknesses  will 
turn  into  the  target  of  the  malicious  logic,  it  was  meant  to 
prevent. 

It  is  important  to  recognii--;  that  several  of  the  ideas 
presented  in  [7)  support  a  fault  tolerance  approach  to  the 
denial-of-service  threat.  These  ideas  include  the  detection 
of,  and  recovery  from,  denial-of-service.  Recovery  may 
require  the  use  of  redundant  services  in  order  to  maintain 
proper  service.  These  ideas  are  straight-out  of  accepted 
fault  tolerance  concepts. 

Current  research  is  directed  towards  extending  the 
schemes  presented,  determining  their  effectiveness, 
devising  additional  extensions  of  fault  tolerance  techniques, 
and  analyzing  the  similarities  between  fault  tolerance  and 
computer  security.  One  example  of  an  application  domain 
which  must  be  addressed  are  Database  systems.  These 
present  many  additional  opportunities  (e.g.,  via  locking)  to 
cause  denial-of-service  19]. 

The  connection  between  fault  tolerance  and  computer 
security  has  beer,  made  by  the  observation,  that  the  effects 
of  malicious  logic  can  be  classified  under  the  fault  class  of 
"by  intent".  The  use  of  design  fault  tolerance  and  NVP  is 
alluded  to  in  [6],  however,  the  possibility  of  the  deliberate 
nature  of  the  faults  is  not  mentioned.  This  paper  has  taken 
a  first  look  at  how  design  diversity  could  be  used  against 
maiicious  logic. 

APPENDIX 

Background  Devious  Actions 

Can  a  Trojan  Horse,  inadvertently  used  by  an  NVP  system, 
perform  devious  actions  in  the  background  while  producing 
valid  results  to  be  voted  on?  This  question  certainly  needs 
much  more  attention,  but  initially  the  following  points  are 
made. 


1)  The  whole  idea  of  NVP  is  that  many  of  a  version's  actions 
(e.g.,  calls  made  as  well  as  data  generated)  are  voted  on. 
Thus,  these  background  devious  actions  will  either  be 
masked  out  entirely  or  severely  limited.  An  obvious  trade¬ 
off  between  degree  of  risk  ana  performance  exists  here. 


2)  Input  to  each  version  of  an  NVP  system  needs  to  be 
obtained  from  different  sources.  If  each  version  obtains  the 
same  bad  data,  then  the  masking  capability  of  NVP  could  be 
defeated.  By  analogy,  if  each  version  of  an  NVP  system 
calls  one  version  of  a  common  program  that  contains  a 
Trojan  Horse,  then  masking  out  its  devious  actions  will  not 
be  possible. 


3)  A  multi-pronged  defense  is  advocated.  Thus,  a  collection 
of  on-line  and  off-line  techniques  should  be  used.  If  one 
technique  fails  to  detect  and  prevent  a  devious  action  then 
it  is  hoped  that  others  will  catch  it.  This  concept  is  very 
similar  to  the  idea  of  hierarchical  fault  recovery  in  fault 
tolerance  [16]. 
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1  INTRODUCTION 

1  3  1 1 

The  UNIX®  system  '  ’  1  contains  a  simple,  elegant,  and  powerful 
feature  called  SETUID  [U  S.  Pat.#  4,135,° 'Oj,  This  feature 
allows  a  user  to  temporarily  assume  the  ide  of  another  user 

and  obtain  the  discretionary  access  rights,  a  ae  privileges,  of 

that  user  This  feature  is  used  to  control  privileged  operations 
and  to  build  protected  subsystems.  It  is  invoked  by  giving  a 
program  the  SETUID  property.  Upon  execution  of  such  a 
program,  any  user  executing  the  program  acquires  the  access 
rights  and  privileges  of  the  owner  of  the  program  It  is  the 
responsibility  of  the  setuid  program  to  prevent  abuse  of  the 
additional  access  rights  it  grants.  This  paper  informally  describes 
some  ol  the  security  implications  of  this  facility,  and  describes 
several  alternatives  which  can  provide  'imilar  functionality  with 
better  security. 

The  first  section  of  the  paper  defines  some  important  terms  (We 
assume  basic  familiarity  with  UNIX,  but  not  with  the 
SETUID/SETGID  concepts.)  Next,  the  paper  examines  some  of 
the  properties  and  uses  of  this  mechanism,  examines  some  of  the 
security  implications  of  it,  and  finally  discusses  alternative 
methods  of  providing  similar  or  equivalent  functionality 

2  DEFINITIONS 

In  this  section,  we  define  some  of  the  important  terms  and 
concepts  used  in  the  remainder  of  the  paper.  There  arc  several 
slightly  different  implementations  of  the  system  calls  and 
semantics  of  SETUID/SETGID  in  different  flavors  of  the  UNIX 
system;  we  have  tried  to  keep  the  points  made  in  this  paper 
generic  and  applicable  to  virtually  all  of  them.  We  will  ignore 
some  details  and  complications  which  arc  of  limited  interest  in 
order  to  keep  the  discussion  simpler. 

In  UNIX  systems,  user  names  are  mapped  onto  integers  known  as 
user  IDa  during  the  login  process.  This  mapping  can  be  assumed 
to  be  one-to-one  for  this  discussion.  One  distinguished  user,  the 
root  or  superuser,  possesses  all  privileges  to  perform  sensitive 
operations  in  UNIX. 

l  argely  as  a  convenience  in  managing  access  to  files,  and  in  some 
systems  for  accounting  purposes,  users  belong  to  one  or  more 
groups.  A  group  is  simply  an  arbitrary  list  of  users  who  are 
treated  together  for  access  control  purposes.  A  user  is  associated 
with  a  default  group  upon  login,  and  can  change  that  association 
during  his  login  session.  (There  are  several  variations  of  this  in 
different  UNIX  systems,  including  simultaneous  membership  in 


multiple  groups.  We  will  follow  the  original  UNIX  convention  of 
single  group  membership.) 

Processes  in  the  UNIX  system  follow  the  intuitive  definition  of  a 
process  A  process  possesses  many  properties,  but  there  are  a  few 
which  arc  especially  important  to  this  paper: 

•  Real  User  ID  (RU1D).  This  is  the  user  who  is  the  actual 
owner  of  the  process,  i.e.,  the  user  from  whose  login 
process  the  process  is  descended 

•  Effective  User- IP  (EUID)  This  is  the  user  whose 
discretionary  access  privileges  arc  currently  available 
to  the  process.  It  is  normally  the  same  as  the  RlJlD. 

.  Real  Group-ID  (RGID).  This  is  originally  the  default 
group  associated  with  the  real  user  id  It  ear  be 
changed  explicitly  by  the  user  to  any  of  the  groups  to 
which  the  user  is  authorized  (this  is  done  differently  in 
different  versions  of  UNIX  -  the  distinction  is 
unimportant  here) 

•  Effective  Group-ID  (EGID).  This  is  a  group  whose 
discretionary  access  privileges  are  currently  available 
to  the  process.  It  is  normally  the  same  as  the  RGID 

We  will  use  the  notation 

RUID(process) 

EUID(process) 

RGID(process) 

EGID(proccss) 

to  indicate  the  UIDs  or  GIDs  of  a  particular  process. 

The  discretionary  access  control  (DAC)  mechanism  of  UNIX  is 
implemented  by  associating  three  sets  of  mode  bits  with  an  object 
being  controlled  (When  discussing  objects  in  this  paper,  we  will 
generally  refer  only  to  files;  the  conclusions  generally  apply  to 
other  objects  protected  by  owncr/group/other  mode  bits)  All 
such  objects  have  an  owner  and  owning  group,  which  generally 
describe  the  user  id  and  group  the  owner  belonged  to  when  the 
object  was  created  Each  set  of  mode  bits  consists  of  three 
yes/no  permission  bits  which  if  set  allow  read,  write,  and  execute 
access  (oilier  permissions,  such  as  directory  search,  arc  overloaded 
onto  the  same  three  bits)  The  three  sets  of  mode  bits  describe 
the  access  permitted  to  owner  (the  file  owner),  group  (users  in  the 
same  group  as  the  file  owning  group),  and  other  (all  other  users 
and  groups).  If  the  owner  is  attempting  access,  only  the  owner 
bits  are  checked.  If  someone  in  the  owning  group  other  than  the 
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owner  is  attempting  access,  only  the  group  hits  are  checked-  If 
the  attempt  is  by  neither,  the  other  bits  are  cheeked.  The  EUID 
of  a  process  attempting  to  access  an  object  is  used  in  determining 
if  a  requested  access  is  being  made  by  the  owner  ol  the  file;  the 
EGID  is  used  in  determining  if  the  attempt  is  being  made  by 
someone  in  the  owning  group  of  the  file. 

The  SETUID  mechanism  is  invoked  by  setting  the  SETUID 
property  on  a  file.  This  property  is  externally  applied,  like  mode 
bits.  Upon  executing  a  program  file  with  the  SETUID  bit  set,  the 
EUID  of  the  resulting  process  is  set  to  the  owner  of  the  program 
file  The  SETGID  mechanism  works  similarly,  but  the  EGID  of 
the  process  is  affected.  SETUID  and  SETGID  can  be  used 
separately  or  together  on  an  executable  file. 

It  is  useful  to  be  able  to  talk  succinctly  about  the  set  of  files  to 
which  a  user,  group,  or  process  has  access.  We  describe  these  sets 
with  the  following  notation: 

FILES(mo(/e,  user) 

FlLES(moiie,  group) 

FlEES(mode,  process) 

This  construct  represents  the  enumeration  of  the  entire  set  of 
files  in  the  system  which  can  be  directly  accessed  in  the  way 
described  by  mode  (e  g.,  read,  write,  execute,  search)  by  that  user, 
group,  or  process.  The  definition  of  “accessible''  must  be  made 
very  carefully,  as  we  describe  in  the  later  "Security  Implications 
of  SETUID”  section.  We  will  use  the  operator  “+”  to  represent 
the  set  union  operation  when  discussing  operations  on  these  sets. 

3  PURPOSE  OF  THE  SETUID /SETGID  MECHANISM 

The  SETUID/SETG1D  mechanism  is  used  in  practice  for  two 
functions,  which  are  quite  distinct  and  separable  but  arc  often 
confused: 

J.  SETUID/SETGID  is  used  as  the  privilegc-gi anting 
mechanism  in  UNIX. 

There  are  many  “privileged”  operations  in  UNIX. 
Control  of  these  is  coarse-grained:  one  specific  user,  the 
“superuser",  has  all  privileges  In  addition,  control  over 
certain  very  special  system  filc3  (e  g.,  /dev/kmem,  the 
pseudo-file  representing  the  memory  image  of  the 
kernel)  is  often  invested  in  SETGID  programs,  which 
may  perform  sensitive  operations  on  those  files.  (Some 
of  these  operations  are  privileged  because  of  the 
damage  they  can  do  if  misused,  not  because  of  the 
inherent  sensitivity  of  the  operation.  For  example,  for 
a  user  to  simply  list  his  own  active  processes  requires 
accessing  the  kernel  memory  image  in  a  standard  UNiX 
system.) 

2.  SETUID  and  SETGID  are  used  to  build  protected 
subsystems. 

A  protected  subsystem  in  UNIX  is  implemented  as  a 
SETUID/SETGID  program  (or  family  of  programs) 
which  control  access  to  a  file  or  files  owned  by  the  same 
user/group  as  the  program(s).  Any  user  cxeriil  ing  such 
a  program  temporarily  acquires  access  to  the  files,  but 
all  his  accesses  are  mediated  by  the  program 
Examples  of  such  subsystems  include  mail  systems 
(which  protect  the  mail  data  base),  data  base  systems, 
bulletin  board  systems  such  as  notes  and  news,  games 
(which  protect  scoring  information),  other  software 
packages  which  want  to  keep  statistics  or  other  side 


information  which  they  do  not  want  users  to  be  able  to 
access  except  from  inside  the  package,  and  programs 
which  wish  to  implement  their  own  discretionary  access 
policy. 

The  operating  system  kernel  itself  provides  no  finer  control  over 
its  privileged  operations  than  the  superuser  privilege,  which  is 
all-powerful.  All  processes  with  an  EUID  or  IlUID  equal  to  that 
of  the  superuser  (for  example,  a  process  generated  by  executing  a 
SETUID  program  which  is  owned  by  the  superuser)  possess  all 
possible  kernel  privileges  and  can  use  them  or  abuse  them  as  they 
wish.  It  is  the  program  itself  which  must  correctly  do  only  those 
privileged  operations  that  arc  consistent  with  the  security  of  the 
system.  For  example,  it  is  the  responsibility  of  the  login 
program,  a  SETUID  program  owned  by  the  superuser,  to  verify 
that  a  user  presents  the  correct  password  for  a  specific  U1I) 
before  it  grants  the  user  access  to  the  system  as  that  user. 

Some  privileged  operations  are  implemented  in  user-level 
processes  by  SETUID/SETGID  programs.  These  programs  are 
sometimes  superuser  programs,  but  need  not  always  be.  For 
example,  some  set  the  EUID  to  a  special  non-superuser  U1D  or  set 
EGID  to  a  special  GID,  where  the  U1D/GID  is  the  owner  of  some 
special  privileged  object.  Used  in  conjunction  with  the  UNIX 
discretionary  access  mechanism,  this  provides  a  quite  distinct 
mechanism  from  the  kernel-arbitrated  privileged  operations 
mentioned  above.  This  type  of  privilege  typically  involves  the 
manipulation  of  the  special  file  system  objects  like  the 
/dev/kmem  or  /dev/mem  pseudo-files,  which  permit  access  to  all 
internal  data  structures  of  the  operating  system  kernel.  (For 
example,  the  UNIX  ps  command,  which  obtains  the  current  state 
of  all  processes  in  the  system  regardless  of  owner,  obtains  its 
information  in  this  way.) 

SETUID/SETGID  is  a  very  powerful  hut  coarse-grained  privilege 
mechanism.  In  building  a  secure  version  of  UNIX,  it  is  necessary 
to  minimize  the  potential  for  abuse  of  privilege.  The  potential  for 
abuse  of  SEl’UID/SETGID  mainly  comes  from  the  first  point 
above,  the  acquisition  of  privileges  with  SETUID/SETGID.  (A 
companion  paper  4  discusses  a  privilege  mechanism  to  help 
control  the  granularity  problem.)  Abuse  or  incorrect  usage  of  the 
mechanism  to  implement  trusted  or  protected  subsystems  is  also 
possible,  as  we  discuss  below. 

4  SECURITY  IMPLICATIONS  OF  SETUID 

4,1  Interaction  with  Directory  Search  Rules 

'The  general  accessibility  of  files  to  a  process  in  UNIX  can  be 
described  as  the  union  of  files  accessible  to  its  user  and  to  its 
group.  Since  there  are  potentially  two  different  user  id’s  and  two 
different  group  id’s,  however,  the  details  of  this  become 
complicated.  Let  us  assume  for  a  moment  that  the  meaning  of 
FILES) mode, process)  is  defined  as  the  set  of  files  which  the  open 
system  rail  can  successfully  open  with  the  specified  mode  The 
basic  rule  for  some  specific  mode  mode  in  the  set  (read,  urite, 
cicrulej  would  appear  to  he 

FI  1  ,KS(  mode, process)  — 

FILES) mo(/c,EUlI)(pruress))  f 

FI  I  .KS(  mode.EGI  I )( proress)) 

(We  assume  that  files  available  via  "other"  access  permission  are 
included  in  one  or  more  of  the  component  sets).  There  arc  two 
non-intuitive  points  that,  we  would  like  to  make  about  the  above 
description. 
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1.  The  access  rules  for  UNIX  open  specify  that  the  access 
checks  are  done  using  effective  u  r  and  group,  id's. 
However,  by  using  an  unprivileged  system  call 
(scluvi/  'dguf)  to  set.  its  KUID/KGID  to  its 
RUID/KGID,  a  process  can  in  fact  often  access  both 
sets  of  files.  The  extent  to  which  this  is  possible  is 
highly  dependent  on  the  mode  settings  on  directories 
and  on  the  nuances  of  the  particular  UID/GI1) 
manipulation  primitives  provided  on  the  particular 
UNIX  version  being  used.  (It  may  in  some  cases  require 
spawning  sub-processes  and  other  trickery.) 
Consequently,  the  real  user  and  group  entries  must  be 
included  in  this  computation  to  cover  this  case  To 
take  this  into  account,  the  corrected  formula  should 
include  the  terms 

+  FII  J‘'S(mndc,RUII)(proees.v)) 

4  FI I  jISS( m 0<fc,RGI  D(process)) 

2.  Under  our  working  assumption  that  we  define  the 
semantics  of  KIRKS  using  UNIX’s  open  system  call, 
even  the  corrected  definition  above  is  incomplete  In 
fact,  KIKKSfmodc, process)  can  be  a  superset  of  the 
union  shown  above  due  to  the  interaction  of  directory 
search  access  rules,  access  modes,  and  the  ItUID/EUID 
and  RGID/ICGII).  Because  of  the  directory  search  rules 
in  UNIX,  it  is  possible  to  have  otherwise  accessible  files 
that,  cannot  be  found  because  they  arc  located  in  an 
unsearchable  subtree  of  the  file  system.  A  different 
user  may  be  able  to  find  them,  but  be  unable  to  access 
them.  The  combination  of  accesses  provided  by 
different,  effective  and  real  id’s  can  be  used  to  locate, 
then  access,  such  files.  An  example  is  shown  below. 

A  curious  feature  of  the  use  of  mode  bits  to  deny  access  can  show 
up  in  computing  the  FILES  relation.  Files  belonging  to  a  user 
may  be  inaccessible  to  the  user  because  of  the  w  ay  mode  bits  arc 
checked.  This  intentionally  permits  an  owner  to  explicitly  deny 
himself  or  his  group  access  to  an  object.  If  the  oth(r  or  group 
permissions  allow  access  to  the  KUID/KGID  of  an  object,  then  a 
SKTUIR/SKTGI1)  process  could  access  files  belonging  to  the  user 
himself  which  he  could  not  access  otherwise. 

In  order  to  illustrate  the  second  point  above,  we  can  create  an 
example  in  which  a  SKTUID  process  (running  with  non  equal 
KU1D  and  RU1D)  can  access  files  which  a  process  owned  and 
operated  by  either  UI1)  alone  could  not.  access  (Figure  1).  First-, 
we  create  a  directory  dir  which  allows  search  access  only  to 
KUII).  Within  dir,  we  next  place  a  directory  subdir,  which 
allows  search  access  to  both  the  KUII)  and  HUH).  Within 
directory  dir/Bubdir,  *ve  place  subdirectories  and  files  (filel  and 
dir2  in  Figure  1)  to  which  only  the  KUII)  has  access.  The 
SKTUil)  process  first  changes  to  directory  dir/subdir  as  its 
working  directory.  Then,  it-  uses  the  setuid  system  call  to  set  its 
Kill  1)  to  the  old  HUH).  The  files  and  directories  in  dir/subdir 
arc  now  available  to  the  process.  A  process  belonging  to  the 
original  KUII)  could  not  have  accessed  the  files,  though  it  could 
find  them.  A  process  belonging  to  HUH)  could  not  have  found 
them 
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Fig.  1  -  Gateway  Directory  Example 


Wr  refer  to  dir  as  a  “gateway  directory"  later  in  this  paper. 
(There  are  contexts  in  which  this  could  actually  be  useful.  For 
example,  a  mail  directory  could  contain  mail  files  owned  by 
individual  users,  but.  be  inaccessible  except,  through  a 
SETU1D/SKTG1D  program  and  a  gateway  directory  owned  by  its 
owner/group.  This  minimizes  the  amount  of  privileged  work  that 
must  be  done  by  the  SETUID/SKTGH)  program,  as  it  can  simply 
change  diiertorics  to  the  mail  directory  hidden  beneath  the 
gateway  directory,  reset  its  EUID/EG1D  to  the  RUJD/RGID,  and 
then  proceed  with  its  work  using  only  the  access  permissions  of 
the  executor  ) 

These  non-intuitive  aspects  of  SETU1D/SETGID  appear  to  be 
potential  security  problems  in  practice  only  if  administrators  or 
users  incorrectly  try  to  isolate  a  subtree  <>f  i lit;  file  system  by  a 
change  in  discretionary  access  permissions  at  its  root  They  also 
cause  some  problems  with  formal  models,  as  discussed  later. 

4.2  Unexpectedly  Granting  Access  to  Files 

lu  a  SKTUID/SKTGII)  protected  subsystem  which  obtains 
parameters  such  as  file  or  object  names  from  a  user,  the 
application  must  be  extremely  careful  to  insure  that  the 
operations  performed  by  the  subsystem  correctly  avoid  violating 
the  protection  which  the  application  is  supposed  to  provide.  This 
points  out  the  general  problem  of  unintended  grant  of  access  to 
the  files  of  the  owner  (or  owning  group)  of  the  SKTUID  (SKTGID) 
program  Any  files  belonging  to  the  owning  user  (owning  group) 
must  be  protected  by  the  application  in  addition  to  the  file(s)  that 
it  is  designed  to  protect.  This  means  that  a  lot  of  care  must  be 
taken  in  the  design  of  SKTUID/SKTGII)  programs,  inexperienced 
programmers  in  particular  should  beware  of  using  the  SKTUID 
property  on  programs  which  they  allow  others  to  use 

A  classic  example  of  this  problem  is  the  UNIX  mail  program  of 
early  Version  6  UNIX  The  program  ran  SKTUID  to  superuser  in 
order  to  be  able  to  write  mail  into  a  user’s  privately-owned 
mailbox  When  an  option  was  added  to  the  mail  program  to 
allow  a  user  to  make  it  t  ake  its  input  from  a  file,  a  corresponding 
check  t.c  see  if  the  user  was  supposed  to  be  able  to  access  that  file 
was  n of  added.  Since  the  superuser  can  read  any  file,  a  user 
could  obtain  a  copy  of  any  file  in  the  system  by  mailing  it  to 
himself  To  make  it  easier  to  avoid  this  problem  when  wiihiig  a 
privileged  program,  UNIX  System  V  now  incorporates  the  notion 
of  a  saved  uid,  which  allows  a  superuser  process  to  set  its  KUID  to 
its  (probably  iion-supcniser)  RUIP  and  later  set  it  back.  Using 
this  capability,  a  program  ran  temporarily  suspend  its  privileges 
while  performing  commands  requested  by  a  user  (and  thus  allow 
the  kernel  to  perform  its  normal  checks),  and  restore  them  later. 
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4.3  Trojan  Horses 

It  is  clearly  possible  for  any  program  provided  by  another  user  to 
contain  a  Trojan  horse.  The  program  can  access  the  files  of  the 
user  who  executes  it,  and  can  siphon  off  data  and  save  it  for  the 
the  provider  of  the  Trojan  horse  to  peruse  later.  This  is  a  generic 
problem  with  trusting  any  program  written  by  another  user,  and 
is  not  specific  to  SETUID/SETGID  programs.  SETUID/SETGID 
does  open  the  possibility  of  a  new  kind  of  Trojan  Horse,  however, 
?s  described  below. 

One  method  for  a  user  to  attempt  to  encapsulate  a 
SETU !  1) /SETG I D  process  is  to  insure  that,  the  user’s  files  are  not 
accessible  to  the  EUID/EGI1)  under  which  the  process  operates, 
and  therefore  cannot  exceed  the  bounds  of  the  user’s  intent 
However,  one  SETUID/SETGID  program  car.  execute  another 
using  the  fork  and  tree  system  calls.  Thus,  unless  the  access  of 
one  SETUID/SETGID  program  to  all  other  such  programs  can  be 
totally  denied,  the  user  must  protect  against-  all  possible 
EUIDs/EGIDs  which  the  program  might  be  able  to  assume.  It  is 
straightforward  to  plug  this  hole.  For  example,  one  can  forbid  an 
uprivileged  SETUID/SETGID  process  to  have  a 
SETUID/SETGID  process  with  a  different 
EU1D/EGID/RUID/RGID  as  a  descendent  (in  any  generation). 
(It  is  necessary  to  restrict  this  to  unprivileged  processes  to  permit 
programs  like  login  to  work  as  they  now.)  Another  approach 
was  taken  by  IBM’s  Secure  XENIX®  ,  which  solves  this  problem 
by  allowing  SETUID  processes  to  be  executed  only  by  a  direct 
user  command.  (In  that  system,  SETUID  functionality  still 
implements  the  privilege  mechanism.)  Either  approach  makes  it 
impossible  to  accumulate  access. 

Few  UNIX  machines  in  environments  with  skillful  system 
programmers  and  without  routine  housecleaning  are  free  of 
hidden  SETUID  programs  which  make  their  ow'ncr  the  superuser 
or  some  other  user.  (The  names  of  such  programs  often  start 
with  a  *.*  so  that  they  don’t  normally  show  up  on  directory 
listings,  or  use  the  same  name  as  a  valid  SETUID  program  in  the 
hopes  of  tricking  a  casual  observer  into  thinking  that  they  arc 
simply  copies  of  that  program.)  A  useful  feature  added  to 
Berkeley’s  version  4.3  UNIX  system  is  the  ability  to  disable 
SETUID/SETGID  for  specific  mounted  file  systems  This  makes 
it  easier  to  insure  that  only  authorized  programs  can  perform  this 
function,  and  makes  importing  foreign  file  systems  much  less 
dangerous. 

Trojan  horse  code  which  a  malicious  user  can  arrange  to  have 
executed  by  a  user  whom  he  is  trying  to  subveit  can  normally 
execute  any  SETUID/SETGID  program  available  to  that  user, 
with  arbitrary  (presumably  malicious)  parameters.  (This  is  one 
reason  that  a  trusted  path*  must  be  provided  to  all  TCB  services 
in  a  B3/A1  system.)  The  IBM  Secure  XENIX  approach  of 
allowing  SETUID  commands  to  be  executed  only  by  direct  user 
command  prevents  this. 

4.4  Modeling  Issues 

There  are  some  security  modeling  issues  which  arise  because  of 
SETUID/SETGID.  These  issues  may  or  may  not  present 
problems  in  practice,  but  they  cannot  be  ignored. 

*  A  process  with  the  EUID  of  a  user  who  isn’t  even  logged 
in  can  get  access  to  files.  This  is  somewhat  peculiar,  as 
the  effective  user  will  not  have  passed  the 
authentication  procedures,  a^id  may  not  even  be  a  valid 
user  at  the  time  of  access0.  It  is  possible  that  this 
could  result  in  a  violation  of  certain  security  policies, 
e.g.,  policies  which  limit  the  times  of  day  during  which 
specific  users  are  allowed  to  use  the  system.  (Such  a 


limitation  might  be  due  to  sensitive*  data  being  present 
on  the  system  only  during  specific  periods;  the  intent  ol 
si.cli  a  policy  could  clearly  be  violated  by  a  SETUID 
program.)  It  is  non-triviai  to  validate  the  user 
represented  by  the  new  EUID  at  the  time  of  execution 
of  the  SETUID  program,  as  that  would  require  the 
kernel  to  perform  the  revaluation  and  that  function  is 
now*  performed  by  user-level  processes  in  UNIX.  (One 
solution  to  tliis  problem  is  discussed  in  section  5. 2.) 

•  Accurately  modeling  discretionary  access  in  an 
unmodified  UNIX  is  inextricably  related  to  the  file 
system  contents  and  the  properties  of  all 

SETUID/SETGID  programs  in  the  system. 
Discretionary  security  models  of  UNIX  can  be  simplified 
if  they  model  the  “maximum  case”  of  access,  classifying 
as  accessible  those  objects  whose  access  modes  would 
allow  access,  shouid  the  object  ever  be  reachable.  (This 
leads  to  an  overstatement  of  access  in  the  security 
model.)  However,  this  simplification  docs  make 
modeling  unusual  encapsulation  methods  based  on  DAC 
(like  the  earlier  example  of  “gateway  directories”) 
difficult  or  impossible. 

There  is  no  obvious  simple  way  to  accurately  model  the  effects  of 
all  the  SETUID/SETGID  programs  in  a  system  on  the 
discretionary  security  policy  unless  all  possible  inputs  and  effects 
of  those  programs  are  characterized.  It.  will  be  interesting  to  see 
how  implementors  of  B3  and  A1  systems  with  SETUID/SETGID 

model  it. 

4.5  Integrity  of  StiTUlU/SFiTGlD  Programs 

In  order  to  prevent  the  subversion  of  a  SETUID/SETGID 
piogram,  UNIX  systems  must  clear  the  SETUID/SETGID  bits  on 
program  files  any  time  a  change  is  made  to  (at  least)  the  file 
contents,  owner,  group,  or  permissions.  This  would  appear  to  be 
a  ‘given”  in  any  UNIX  system,  but  errors  allowing 
SETUID/SETGID  programs  to  be  subverted  have  existed  in  many 
implementations  in  the  past 

A  popular  way  of  influencing  any  trusted  program  is  to  provide  it 
a  false  environment.  Any  trusted  program  which  obtains 
information  about  its  operating  environment  from  the  user 
executing  it,  either  directly  (e.g.,  names  and  parameters  entered 
by  the  user),  or  indirectly  (e  g.,  though  the  UNIX  environment 
variables),  must  be  caieful  what  it  believes.  Subversion  of 
programs  by  influencing  their  environment  is  a  source  of  a  largo 
number  of  errors  which  have  been  founH  ip  SETUID/SETGID 
programs,  especially  large  and  complicated  programs.  One 
example  of  such  a  subversion  occurs  in  programs  which  blindly 
execute  a  program  name  passed  to  them  in  an  environment 
variable.  For  example,  by  changing  the  default  name  of  a 
normally-trusted  sub-command  before  executing  such  a  program, 
a  user  can  get  a  trusted  program  to  supply  data  it.  should  not,  or 
even  to  execute  a  Trojan  horse.  Some  of  the  subversions  which 
are  possible  with  existing  programs  in  wide  use  are  best  left 
unpublished  (especially  those  involving  SETUID (SETC II)  shell 
scripts,  some  of  these  bugs  are  hard  to  fix).  The  only  real  cure  for 
this  problem  is  for  trusted  programs  to  operate  in  an  environment 
which  the  user  cannot  influence,  or  for  such  programs  to 
disbelieve  their  environment  completely  (or  to  verify  ;t,  where 
possible). 
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4.0  Interaction  with  Extensions  to  UNIX 


Ii  is  non-trivial  to  foresee  all  the  ramifications  of 
SETUID/SKTGID  whcr.  extending  UNIX.  For  example,  Berkeley 
UNIX  introduced  the  concept  of  allowing  a  process  to  operate 
with  multiple  groups  simultaneously  active.  That  is,  a  process  in 
Berkeley  UNIX  has  associated  with  it  a  list  of  GIDs,  and  access 
to  an  object  is  allowed  if  any  of  those  groups  is  permitted  that 
access  This  is  very  convenient  operationally,  and  facilitates 
sharing  among  groups.  In  this  model,  it  is  not  obvious  which 
group  to  associate  with  a  newly-created  file  or  directory.  The 
approach  taken  by  Berkeley  is  to  use  the  owning  group  of  the 
directory  in  which  the  object  was  created,  even  if  the  process  (and 
if.*?  user)  are.  not  members  of  that  group.  The  rules  for  setting  the 
SKTCill)  hit  on  a  file  allow  the  owner  of  a  file  to  set.  it  If  the 
owner  sets  the  S1STG1I)  hit  on  a  newly-created  file  to  whose 
owning  group  he  does  not  belong,  the  resulting  SKT0I1)  program 
would  allow  the  user  access  to  files  using  the  access  rights  of  a 
group  to  which  lie  does  not  belong.  This  bug  was  present  in 
earlier  releases  (c.g.,  4.1)  of  Berkeley  UNIX,  but  the  system  now 
prevents  this  by  insuring  that  the  owning  group  on  a  file  is 
contained  in  the  sot  of  groups  of  the  process  before  the  SKTGII) 
bit  is  allowed  to  be  set.  This  cautionary  tale  indicates  that  the 
security  ramifications  of  any  change  to  the  discretionary  access 
mechanisms  of  UNIX  should  be  examined  carefully. 

5  REPLACEMENTS  FOR  SETULD/SETGU) 

The  remainder  of  this  paper  discusses  three  different  methods  to 
provide  the  functions  performed  by  SETUID/S1CTG1I)  on  UNIX. 
These  thodc.  display  decreasing  degrees  of  modification  to 
UNIX  and  display  various  degrees  of  compatibility  with  existing 
programs  which  use  SKTUID/SUTGID  (including  essentially  full 
compatibility).  The  third  method  presented  is  a  part  of  a 
general-purpose  privilege  mechanism  which  we  believe  is  superior 
in  controllability  and  security  to  SKTUID/SKTCII)  while 
remaining  compatible  for  most  SRTUID/SKTGII)  programs.  All 
three  offer  more  secure  control  over  the  privileges  in  UNIX  than 
unmodified  Sl'Tl  J1D/SKTG1I)  mechanisms,  and  all  three  allow* 
the  creation  of  protected  subsystems. 

5.1  Restricted  Environments 

Gould  used  a  different  approach  from  SKTUID/SETGIP  for 
kernel  integrity  and  control  of  privilege  *n  its  02-ratcd  UTX/32S 
UNIX  system.  When  Gould  began  work  on  its  system  in  19h5, 
there  was  considerable  debate  in  the  security  community 
concerning  the  inherent  security  of  systems  which  use  the 
SETUID/SETGU)  concept.  This  debate  is  still  not  totally 
resolved  today.  While  quite  interested  in  its  outcome,  we  were 
unwilling  to  wait  until  the  debate  was  finished  to  implement  our 
C2  UNIX  system.  So,  in  order  to  facilitate  the  formal  evaluation 
of  our  system,  we  removed  the  SFJTUID/SETG1D  facility 
completely.  This  was  a  controversial  decision.  The  lost 
functionality  was  implemented  using  trusted  server  processes, 
originally  introduced  as  part  of  the  integrity  mechanism  of  the 
system,  operating  outside  restricted  environments. 

The  restricted  environment  is  a  concept  based  on  the  UNIX 
chroot  system  call,  which  restricts  file  system  access  of  a  process 
to  a  subtree  of  the  UNIX  file  system.  In  Figure  2,  we  show  a 
subset  of  a  UNIX  file  system.  The  directory  /unpriv_j*e  forms 
the  root  of  the  unprivileged  environment  which  is  encircled  in  the 
figure.  Users  operating  inside  the  environment  have  no  way  to 
locate  files  outside  it  From  the  standpoint  of  a  process  operating 
inside  the  restricted  environment,  /unpriv_re  is  the  root  of  its 
file  system,  and  the  directory  /unpriv_re/mnt  is  addressed  by 
the  path  name  /mnt.  Processes  with  this  limited  visibility  cf  the 
entire  system’s  file  tree  have  no  direct  access  to  system-critical 
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Fig.  2  -  A  UNIX  File  System  with  a  Restricted  Environment 


files  (e.g.,  the  password  file)  or  to  privileged  programs  and  their 
directories,  all  of  which  arc  outside  the  restricted  environments. 
This  makes  it  much  harder  foi  a  user  process  in  a  restricted 
environment  to  affect  the  Trusted  Computing  Base  ('FOB)  of  the 
system  in  any  way. 

Protected  subsystems  can  be  implemented  in  at  least-  two  ways  in 
this  model. 

1.  Make  the  subsystem  a  server  process,  operating  outside 
the  restricted  environment  (Figure  3). 

The  server  process  need  not-  he  privileged  in  general, 
though  the  details  of  implementation  in  our  system 
interfere  with  this  (as  an  unprivileged  process,  it  cannot 
use  the  trusted  interprocess  communication 
mechanism). 

In  Figure  3,  we  show  a  client  program  inside  the 
restricted  environment  communicating  with  the 
subsystem,  which  operates  outside  it..  They 
communicate  via  an  interprocess  communication 
mechanism  known  as  secure  sockets' . 

2.  A  second  method  is  to  run  a  trusted  subsystem  in  a 
restricted  environment,  of  its  own,  with  no  users,  along 
with  all  the  files  to  which  it  is  to  control  access  (Figure 

4)- 

Clients  communicate  with  the  subsystem  via  a  server 
which  arbitrates  references  and  performs 
communications  between  server  and  client  We  did  not 
support  multiple  restricted  environments  on  the  first 
system  release,  so  we  have  no  field  experience  with  this 
approach.  Multiple  environments  will  be  a  feature  m 
future  releases,  so  this  method  will  be  available. 

This  approach  is  capable  of  implementing  mutually 
suspicious  subsystems  ,  and  requires  minimal  or  no 
change  to  application  programs.  It  is  a  very  strong 
method  for  isolating  subsystems,  and  is  probably  the 
method  of  choice  for  operating  large  existing 
SETU1D/SETG1I)  applications  such  as  databases  where 
the  extra  isolation  Joes  not  interfere  with  functionality. 
Figure  4  .shows  this  case. 

The  privilege  control  mechanism  we  used  with  restricted 
environments  is  a  simple  one:  processes  must  be  born  privileged, 
i  e.,  they  must  be  designated  by  a  privileged  parent  as  inheriting 
the  privileges  of  the  parent  when  created  (The  one  initial 
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Fig.  3  -  An  Application  Implemented  as  a  Server 


Fig.  4  -  A  Server  Mediating  between  Client  and  Application  , 


process  is  privileged.)  AH  privileged  operations  arc  executed  by 
privileged  server  processes  which  arc  created  to  serve  that 
function  and  that  function  alone.  Privileged  servers  operate 
outside  the  restricted  environment  subset  of  the  file  system,  and 
therefore  system  files  are  visible  to  them.  Because  the  original 
UTX/32S  is  a  C2  system,  it  was  not  deemed  necessary  to 
subdivide  the  system  privileges  (i.c.,  implement  a  least-privilege 
TCB).  So  most  privileged  processes  still  run  with  essentially 
superuser  privileges  in  this  model. 

When  using  server  processes  to  perform  functions  formerly 
performed  directly  by  a  privileged  system  call,  a  set  of 
subroutines  can  be  provided  to  make  some  of  the  communications 
invisible  to  clients.  The  subroutines  establish  communication 
with  appropriate  privileged  processes,  pass  parameters  to  it,  and 
generally  behave  as  if  they  perform  the  service  directly.  If  such 
subroutines  are  substituted  for  a  few  key  system  calls  and  service 
subroutines  (e  g ,  the  password  validation  function),  many 
programs  need  only  be  recompiled  in  order  to  run. 

One  of  the  first  questions  people  ask  about  the  use  of  server 
processes  is  its  performance.  It  turns  out  that  a  few  operations 
actually  go  faster,  since  the  server  process  already  exists  and  a 
connection  to  it  is  very  cheap  to  make  Other  operations  must- 
still  create  an  additional  process,  so  they  are  somewhat  slower. 
Overall,  there  is  usually  little  difference  in  performance  between 


this  system  and  the  non-secure  UTX  system  used  as  its  base.  (A 
more  important  performance  drain  comes  from  auditing  -  a 
function  that  all  secure  systems  have  to  implement.) 

6.2  Restricted  SETUID/SETGID 

An  cxlcnsion  to  the  concept  of  restricted  environments  is  to  allow 
the  limited  use  of  SETUID/SETGID  within  a  restricted 
environment.  This  SETUID/SETGID  with  modified  semantics 
would  not  permit  a  process  to  acquire  any  system  privileges,  nut 
would  allow  the  controlled  access  to  data  files  as 
SETUID/SETGID  does  now.  In  other  words,  it  would  be  used 
only  for  implementing  the  protected  subsystem  component  of  the 
SETUID/SETGID  functionality  described  in  the  early  sections. 
This  would  allow  the  vast  majority  of  SETUID/SETGID 
application  programs  to  work.  (Those  which  also  perform 
privileged  operations  reserved  for  the  superuser  would  not  be  able 
to  execute  the  privileged  system  calls  required,  and  would  need  to 
be  modified). 

One  of  the  weaknesses  of  SETUID/SETGID,  even  in  this  limited 
form,  is  the  t-ransititive  acquisition  of  discretionary  access  by 
executing  a  chain  of  SETUID/SETGID  processes,  as  described  iu 
section  4.3.  It  can  be  limited  as  described  there. 

As  described  earlier,  another  weakness  of  SETUID/SETGID  is 
that  such  programs  can  provide  accidental  access  to  files  owned 
by  the  EUID/KCID  other  than  those  it  is  supposed  to.  Three 
ways  of  avoiding  this  problem  come  tc  mind: 

1.  Careful  programming.  (This  can  also  be  described  as 
“wishful  thinking”.) 

Programmers  must  keep  a  long  list  of  cautions  in  mind 
when  building  SETUID/SETGID  programs*  .  Knowing 
as  many  case  histories  as  possible  of  errors  that  have 
been  made  in  the  past  is  helpful,  but  keeping  the 
functionality  of  such  programs  minimal  is  really  the 
best  protection  available.  Many  existing  applications 
have  been  heavily  examined  and  tested,  and  many  arc 
undoubtedly  trustworthy. 

2.  Operate  the  subsystem  inside  a  restricted  environment 
which  contains  the  client  as  described  in  section  6.1, 
but  leave  all  other  files  owned  by  the  KUID/EGII) 
outside  »t.  This  eliminates  any  possible  accesses  to 
those  files. 

3.  Generate  a  pseudo  user  name  which  will  own  the 
program  and  its  minimum  necessary  files. 

This  name  would  not  correspond  to  any  valid  login 
account,  which  would  help  insure  that  the  user  id  would 
not  be  used  for  anything  but  its  intended  purpose,  and 
would  be  used  only  by  the  subsystem  and  its  files.  This 
fixes  the  modeling  problem  with  a  non-logged-in  user 
being  able  to  access  files,  and  reduces  the  management 
overhead  of  insuring  that  no  files  are  accidentally 
accessible  via  this  program.  A  veision  of  this  could  be 
used  now  in  the  administration  of  some  of  the  protected 
subsystems  of  UNIX,  such  as  notes  and  uucp,  but 
generally  is  not  (the  special  pseudo  users  are  in  fact, 
allowed  logins,  which  makes  auditing  of  the  actions  of 
users  impossible  if  more  than  one  user  possesses  the 
ability  to  login  as  a  particular  pseudo-user) 

Several  problems  could  arise  with  a  naive  implementation  of  this 
limited  SKTU’D/SKTGII)  in  a  secure  system  For  example,  audit 
trail  information  must  still  log  the  actual  user  identity,  not  the 
one  assumed  by  the  SETUII)  program  There  seem  to  be  no 
significant  problems  implementing  this  and  the  other  minor 
changes  that  are  needed,  and  the  functionality  is  fully  compatible 
with  the  majority  of  applications. 
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5.3  Use  of  a  General  Privilege  Mechanism 

At  the  TCSl'XJ7  1(2  and  higher  levels  of  security,  il  is  necessary  to 
limit  the  privileges  that  even  a  privileged  program  can  exercise. 
That  is,  even  a  privileged  program  lias  to  operate  in  a  mode  such 
that  it  can  execute  only  privileged  operations  which  are 
mandatory  for  it  to  perform  its  intended  function.  This  is  to 
reduce  the  damage  that  a  Trojan  horse  or  an  error  eould  cause 
There  arc  several  possible  models  and  implementations  which  can 


privilege-set  methods,  and  probably  others.  A  companion  paper 
describes  a  privilege-set  based  mechanism  which  eliminates  the 
need  for  SICTUII)  programs  as  a  privilege-control  mechanism. 
That  paper  concentrates  on  the  privilege  aspects  of  the 
mechanism  This  section  describes  the  use  of  that  mechanism  for 
implementing  protected  subsystems.  A  basic  premise  of  the 
mechanism  is  that  it  should  be  possible  to  fully  enumerate  and 
control  all  privileged  operations  in  a  secure  system,  but  the  bulk 
of  this  discussion  is  oriciued  toward  its  use  ns  a 
SHTUID/SHTGII)  replacement.  The  mechanism  would  be  used  in 
similar  ways  to  help  construct  the  T( dt  of  a  least- privilege  H2 
sysi  cm,  but  we  will  defer  that  discussion. 

For  our  purposes,  all  privileged  operations  in  the  system  call  be 
described  by  tuples  of  the  form  (subject,  operation,  object)  The 
subject  is  the  user,  the  operation  is  the  operation  that  the  user 
wants  to  perform,  and  the  object  is  the  system  object  on  which 
the  operation  is  being  performed.  (The  object  is  sometimes 
obscure  when  discussing  a  privilege  like  “DAO  exempt".  In  surli 
cases,  the  object  is  generally  “all  objects  of  a  given  class",  or  the 
kernel  itself )  A  (somewhat  simplified)  description  of  how  this 
scheme  ran  be  used  to  control  access  to  files  in  a  manner  similar 
to  SMTUID/SKTUII)  follows. 

We  permit  the  dynamic  creation  of  privileges  by  designating  any 
file  system  object  as  a  privileged  object.  We  then  create  at  least 
three  privileges  associated  with  that  file,  corresponding  to  the 


UNIX  mode  bits,  read,  write,  and  execute.  (As  before,  other 
operations  such  as  searching  can  be  overloaded  onto  these.)  The 
privilege  (user,  operation,  file)  would  have  to  exist,  and  be 
available  to  a  user’s  process,  ill  order  for  the  process  to  perform 
the  corresponding  operation.  The  details  of  how  privileges  are 
controlled  and  distributed  to  processes  arc  important,  but  are 
discussed  in  the  companion  paper  and  so  will  not  be  reintroduced 
here  Two  important  points  that  are  important  for  an 
understanding  of  this  approach  need  to  be  emphasized:  In 
general,  only  a  program  which  has  been  examined  and  found 
trustablc  for  a  specific  privilege  will  be  able  to  acquire  and 
exercise  the  privilege,  and  only  users  who  are  deemed  trustworthy 
to  exercise  a  privilege  will  be  able  to  do  so  —  regardless  of  what 
programs  they  execute  and  the  privileges  those  programs  are 
trusted  to  use  lloLh  these  limitations  take  the  form  of 
enumerating  the  privileges  available  to  all  users  and  to  all 
programs,  and  placing  their  distribution  completely  under 
adminstralor  control. 

The  function  of  SKTUID/SKTGI1)  when  used  to  build  protected 
subsystems  is  to  insure  that  only  a  specific  set  of  users  (those 
with  access  to  the  SFTU1D/SKTG1D  programs)  can  execute  the 
subsystem,  and  through  it  access  the  data  files  it  protects.  In  our 
model,  the  data  files  protected  by  a  subsystem  are  designated  as 
privileged  objects,  and  any  operation  on  the  files  require  the 
corresponding  privilege  For  example,  the  UNIX  password  and 
authentication  file  /etc/passwd  would  be  a  privileged  object 
The  operations  of  reading  the  password  file  and  writing  the 
password  file  would  then  be  privileged  operations,  and  only 
processes  able  to  exercise  those  privileges  could  read  or  write, 
respectively,  the  password  file.  So,  the  UNIX  login  process  could 
possess  ine  privilege  to  read  the  password  file,  but  not  ihr 
privilege  to  write  it,  whereas  a  password  updating  program  would 
possess  both. 

Figure  5  shows  an  example  of  two  privileged  files  (/ete/passwd 
and  /dev/kmcm)  which  are  accessed  by  two  privileged  programs 
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Fig.  5  An  Fxarnple  o(  Privileged  Objects  and  Programs  (see  text) 


straightforward  to  analyze,  as  this  mechanism  used  in  tins  way 
simply  provides  a  restriction  <_>f  ai'cess,  ami  numot  allow  access  to 
take  place  when  it  could  not  have  before.  (Though  tin*  piivilcge 
mechanism  in  general  will  not  have  that  property,  as  it.  will  be 
used  to  control  kernel  privileges  such  as  “DAO  exempt.")  Breausr 
it  dues  not  change  the  effective  user/group  of  a  process  like 
Sit  rUlD/SKTGID,  the  DAO  implications  are  simple:  the  program 
has  exactly  those  discretionary  access  lights  of  its  executor,  ulus 
the  additional  capability  to  access  appropriate  privilegi  d  objects. 

G  CONCLUSIONS 

'Phis  paper  has  discussed  a  number  of  properties  of  the  UNIX 
SKTUID/SKTGID  mechanism,  concentrating  on  security 
implications  Though  the  SKTUID/SKTGID  mechanism  is  simple 
and  powerful,  it  is  easily  misused  and  abused,  and  appeals  to  be 
inadequate  to  alone  provide  the  fine  degree  of  control  river 
privileges  ami  protected  subsystems  that  is  required  in  a  highly 
secure  system. 

This  paper  has  discussed  three  mechanisms  which  replace  the 
UNIX  SKTU  ID /SKTG 1 D  with  more  controllable  mechanisms. 
The  first  was  used  in  Gould’s  original  secure  UNIX  product, 
UTX/32S  1.0;  it  is  highly  secure,  but  is  non-tr.in.sp:iP%nt  to 
applications.  The  second  is  an  augmentation  of  the  first,  in  which 
a  limited  SKTUID/SKTGID  facility  is  provided  for  trusted 
subsystems.  This  limited  use  of  SKTUID/SKTGID ^appears  to  be 
compatible  with  the  requirements  of  the  TOSKO* .  at  least  at 
levels  of  III  and  below,  and  will  appear  in  future  Gould  systems 
at  02  and  Hi  if  our  implementation  is  successfully  evaluated  by 
the  NOSO  at.  those  levels.  The  third  mechanism,  a  privilege- 
based  model,  represents  an  approach  which  we  believe  to  be  new. 

We  believe  that  the  privilege-based  mechanism  we  have  described 
is  a  candidate  for  replacement  of  the  UETU1 D/S KTG ID  concepts 
in  a  secure  UNIX  system.  It  allows  user-supplied  privileged 
subsystems  and  applications  to  be  created,  without  interacting 
with  its  protection  of  the  TCB.  We  have  not  yet  studied  all  the 
implications  of  this  scheme  on  existing  applications,  but  it 
appears  that  most  SKTUID/SKTGID  programs  will  work 
correctly  without  modification.  We  also  believe  that  it  is  far 
superior  to  SKTUID/SKTGID  for  new  applications.  The 
mechanism  is  not  incompatible  with  SKTUID/SKTGID,  so 
technically,  the  two  features  could  coexist,  this  may  be  reasonable 
in  a  less-secure  environment  or  one  with  only  a  few  key 
SKTUID/SKTGID  programs  which  are  known  to  be  well-behaved. 
Gould  developed  this  mechanism  to  satisfy  the  least-privilege 
requirements  of  the  TOSKO  at  levels  U2  and  above,  a  goal  which 
it  appears  to  fulfill. 


/etc/ad d__user  and  /bin/ps  Three  users,  Hi,  l?2,  anil  U3, 
possess  various  privileges  The  figure  shows  that  Ul  possesses  the 
necessary  privileges  for  /bin/ps,  but  not  for  /elc/a.dd_uscr.  An 
attempt  by  Ul  to  execute  the  /etc/add_user  program  itself 
plight,  be  successful,  depending  on  access  controls  on  the  program 
file,  but  the  program  would  be  unable  to  modify  the  password  file. 
U2  possesses  sufficient  privilege  for  /ctc/add_uscr  to  operate, 
but  not  for  /bin/ps  113  possesses  no  privileges  and  cannot 
successfully  execute  cither  program.  Note  that  the  ability  to 
execute  either  program  is  totally  independent  of  the  the  ability  of 
that  program  to  affect  the  corresponding  privileged  object(s). 
Administrators  need  not  worry  about  the  discretionary  access 
permissions  on  any  of  t  he  files  or  programs  in  his  system  in  order 
to  control  the  upper  bound  of  privileged  operations  which  users 
can  do.  Similarly,  the  administrator  need  not  worry  about  any 
program  which  does  not  possess  the  necessary  privileges  being 
able  to  access  the  privileged  objects. 

One  significant  difference  between  this  method  and 
SKTUID/SKTGID  is  the  ownership  and  privileges  attached  to 
files  created  by  the  privileged  programs.  In  our  privilege  model, 
programs  run  with  UlDs  equal  to  the  executing  user,  so  any  files 
created  belong  to  the  executing  user.  With  SKTUID/SKTGID 
programs,  the  program  owner  is  the  owner  of  any  files  created  by 
the  program.  This  is  an  important  difference  for  programs  which 
create  files  which  they  wish  to  exclusively  control.  (In  our  model, 
the  files  would  be  owned  by  the  HUM),  and  thus  the  program 
would  be  unable  to  protect  them  from  the  user  with  discretionary 
permissions.)  Further,  since  privileges  are  tightly  controlled,  we 
would  not  want  such  applications  to  be  able  to  create  new 
privileged  objects  lightly,  so  new  files  created  by  the  program 
would  not  normally  be  privileged  and  would  therefore  not  be 
under  the  control  o!  the  privilege  mechanism.  To  solve  this 
problem,  one  simply  makes  the  directory  containing  the  protected 
files  the  privileged  object,  rather  than  attaching  privileges  to 
each  protected  file,  and  creates  new  files  within  that  directory. 

The  above  solution  makes  it  possible  for  the  subsystem  to  create 
new  files  which  arc  also  protected  by  the  privilege  mechanism, 
without  needing  the  ability  to  create  privileged  objects  itself 
This  is  a  potentially  visible  difference  for  existing 
SKTUID/SKTGID  applications,  since  some  may  require  the 
ability  to  create  new  privileged  objects;  however,  those 
applications  which  already  create  their  new  files  in  a  private 
directory  can  remain  unchanged.  Because  most  subsystems  want 
to  control  the  ability  of  users  to  delete  files,  such  private 
directories  are  frequently  the  case  now.  A  private  directory  is 
made  necessary  by  UNIX’s  discretionary  access  mechanism  in 
order  to  guarantee  that  the  controlled  files  are  controlled  solely 
by  the  application  Consequently,  the  set  of  unchanged  programs 
includes  most  data  base  programs,  mail  programs,  bulletin  board 
systems,  and  games.  It  appears  that  this  will  present  a  small 
incompatibility  in  practice. 

The  privilege  mechanism  we  have  described  is  separate  from  any 
other  discretionary  or  mandatory  access  control  mechanism,  and, 
like  SKTUID/SKTGID,  is  externally  applied  to  programs  and  files. 
If  access  to  any  object  in  the  system  needs  to  be  controlled,  and 
the  other  access  control  mechanisms  are  too  general  or  otherwise 
inappropriate,  this  mechanism  can  provide  the  fine-grained 
control  needed.  This  mechanism  also  reduces  the  ability  of  DAO- 
exempt  privileges  users  or  programs  to  violate  the  integrity  of 
privileged  objects.  If  a  privileged  user  needs  the  ability  to 
override  the  privilege  mechanism  for  a  particular  privileged 
object,  he  can  be  given  the  appropriate  privilege  without 
compromising  any  other  privileged  objects 
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Abstract 

This  paper  describes  design  and  implementation  aspects  ol  a 
nctwoik  of  Scctite  Xenix  systems.  With  the  advent  ol  seeme 
systems  the  need  arises  to  intei  -connect  these  systems  in  a  secure 
manner.  An  immediate  goal  is  the  interconnection  ol  Secure 
Xenix  systems  with  a  local  men  net.  The  Ti listed  Computer 
System  (evaluation  Crilena  |1]  and  the  DNSIX  secure  nctwoik 
architecture  |2]  are  used  for  deiiving  additional  socuiity  tcipiiie 
inents  in  the  ateas  ol  security  policy  and  accountability  ui  extend 
B2  functionality  to  a  network  of  Seeme  Xenix  systems  j3|.  I’.m 
1  of  the  paper  extends  the  seem ily  iei|tiirements  tc'  the  nctwoik 
enviiontnent,  pan  2  dcsciibes  the  network  security  design,  and 
part  3  adchesses  some  implementation  issues. 

«  M 1.  C.' . _!  i  .  . 

i  •  I'unwiR  invtnu.T 

The  security  mechanism  ol  one  system  must  be  extensible  to 
another  system  on  the  network  with  which  it  communicates.  Ibis 
resells  in  a  network  of  systems  which  aie  governed  by  a  single 
senility  policy.  In  addition  to  mandaioiy  and  discic'tion.ny 
access  rules,  the  relations  between  systems,  their  security  level, 
the  security  level  ol  their  interc  onnection,  and  the  authoii/niion 
level  of  remote  users  and  applications  must  be  taken  into 
consideration  when  objects  arc  accessed 

The  interaction  between  two  systems  is  oigam/cd  inter  sessions 
Sessions  arc  used  to  mediate  all  network  access.  A  session 
consists  of  a  set  of  related  communications,  l  or  the  duration  ol  a 
session,  subjects  and  objects  cm  both  systems  ate  covered  by  the 
same  security  access  titles.  A  session  is,  (Iteicloic,  associated 
with  a  senility  level  to  accomplish  this.  The  session  seemin'  level 
is  derived  fiom  the  security  level  with  which  the  user  logged  in 
A  session  is  lutthei  associated  witit  an  identification  which  is 
used  foi  auditing  security  relevant  nctwoik  events 

All  packets  seni  between  systems  ate  fuuhei  associated  with  a 
security  label.  The  security  label  is  derived  fiom  the  senility  level 
ol  tile  session.  In  a  network  ol  systems  with  difleient  security 
levels  this  label  is  also  used  to  route  packets  accoulmg  to  the 
security  level  ol  intermediate  systems  and  links 

In  the  area  of  accountability  adclilicrn.il  nctwoik  lelated  idem 
tification  and  authorization  data  must  be  maintained  1  hc-so 
’network  profiles’  are  used  to  identity  and  authenticate  icmoic 
users;  they  are  further  used  to  authorize  the  establishment  ol 
sessions. 

t  Xenix  is  a  trademark  of  Microsoll  Gorpoialion. 
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It  is  assumed  that  the  local  atca  nctwoik  undci  mnsidetation  is 
physically  seeme.  Othctwisc  additional  measures  are  needed  ty> 
deal  with  data  eotupiomise  and  data  integuty  The  risk  of  data 
compromise  can  be  reduced  through  link  encryption.  Data 
ititegiity  can  he  unpioved  iliiough  additional  eituyptcd  check 
lields  in  data  packet.",  ie  a  veiy  hostile  cnvitouincut  stiongei 
meastites  such  ns  application  level  end  to  end  enuyption  and 
noliiiization  c'l  packets  will  be  requited. 

Aiic'thcr  tin  cat  to  be  considered  is  denial  ol  service.  Denial  ol 
set  vice  is  sectitity  tele  van'  tl,  b<i  example  aitclit  set  vice  oi 
authentication  service  is  al levied  llnlortunatelv.  it  is  ralhet 
dillicull  to  specify  genet nl  ciiteiia  what  ccmsiilutes  denial  ol 
service.  The  risk  c>l  denial  ol  seiviee  due  ter  excessive  lint  lie  on 
otbet  sessions  ran  bt'  miniuiized  by  giving  each  session  a  law 
shaic  ol  the  nctwoik  resouiee. 

2.  Network  Security  Design 

The  system  architectute  ol  Secuie  Xenix  seuvs  as  the  basis  ol  the 
secure  nctwoik  extensions.  T  he  n listed  compelling  base  ol  Secure 
Xenix  is  enhanced  with  a  session  mechanism  and  with  trusted 
agents  which  handle  all  security  lelated  communication  between 
systems.  The  nctwoik  security  lacihues  rely  upon  fundamental 
leatutes  of  Secuie  Xenix:  access  niediation  to  piotcv.ed  lesouices 
by  the  kernel,  cutoi cement  of  mandatory  and  disc  iciionaiy 
sec  an  ily  policy,  and  the  protection  of  authentication  and  audit 
data  Additionally,  the  misled  lacility  management  ol  Secure 
Xenix  is  augmented  with  nctwoik  scan  ily  management  tunc 
lions 

All  communications  ouginating  outside  the  dusted  computing 
base  .cquirc  the  estalihshment  ol  sessions  in  cutlet  to  mediate 
access  to  the  nctwoik  Sectitity  telated  communication  is  handled 
by  misted  agents.  An  ager.i  usually  lias  a  tounicipaii  on  the 
machine  u  communicates  with,  and  a  client/server  relationship 
exists  between  the  two.  A  simple  datagiam  based  request 
Response  piolotol  is  sulliciem  loi  the  communication  between 
misted  agents.  A  minimal  set  ol  misled  agents  consists  ol  a 
session  setup  seiviee.  an  audit  set  vice,  and  a  nctwoik  manage 
mem  seiviee. 

lUTotc  ;i  user  (or  progiam  on  his  behall)  can  communicate  with 
another  system  on  the  nciwoik  a  session  must  be  established 
This  rcquiies  that  the  user  is  allowed  to  establish  a  session  to  the 
desired  system,  and  that  the  usei  can  be  identilied  and  nullienii 
rated  at  that  system  with  his  cuncni  seemity  level  Igniting 
authentication  issues  foi  the  moment  a  session  is  established  as 


follows.  The  session  setup  service  communicates  the  identity  and 
security  level  of  the  user  from  the  source  system  to  the  target 
system.  At  the  target  system  a  session  server  process  is  created. 
This  process  acts  its  proxy  for  the  user;  it  has  the  user’s  iderit n  \ 
and  security  level  Additionally,  session  control  strumites  are 
dented;  they  are  needed  for  relating  connections  to  sessions 
Session  creation  can  he  combined  with  the  invocation  ol  a  server 
proecss  (or  an  application,  such  as  is  needed  lor  a  I  lie  trnnslci 
program 

Network  areess  can  he  controlled  in  a  centralized  or  in  a 
d N i i huicd  lashion.  When  control  is  cenuali/ed  then  nl!  nelwork 
access  prol lies  art  stored  at  one  place  on  the  network.  When 
control  is  distributed  then  each  system  nl  the  network  has  its  own 
network  a<ecss  profile,  hot  the  centralized  ease  an  aullicmic.i 
non  service  comes  into  play  which  authorizes  a  session  creation. 
In  the  distributed  ease  session  setup  can  be  combined  with 
nclwoik  aiitlieniicaiion,  and  no  authenti  '  at  ion  service  is  needed 
Nelwork  access  pi  of  ties  which  are  maintained  locally  have  the 


The  secure  network  administrator  funtlion  lurthcr  has  to  interact 
with  the  secure  administrator  function  of  Secure  Xenix  to  handle 
the  registration  of  remote  users  and  the  mapping  of  iheir  user 
and  group  identifications  from  one  system  to  another. 

Additional  security  support  services  can  lie  combined  wnh  the 
session  mechanism  such  as  an  encryption  key  service.  II  applita 
tioii--io-applicniion  encryption  is  desired  then  encryption  kevs 
wou'd  he  obtained  at  session  setup.  All  packets  communicated 
h>  that  session  would  then  lie  encrypted  and  decrypted  using 
these  keys. 

?.  Implementation  Aspects 

I  he  implementation  of  the  secure  network  facilities  for  Secure 
Xenix  is  guided  by  these  objectives:  (1)  no  modifications  to 
Sccuie  Xenix  proper  an:  permitted.  (2)  the  network  software 
must  he  structured  according  to  H2  requirements,  and  (3)  the 
software  interfaces  should  he  adaptable  to  suppou  dilleienl 
pintocoh  and  network  inlet  lace  requaements. 


advantage  that  caili  system  adtninisualor  has  control  over  who 
can  access  the  system  f i tun  a  leinote  loialion 

lor  audil  purposes  a  session  is  associ.Ued  wilh  a  unique 
idcnl ■ ! ic nl ii Hi  Audil  iceords  are  generated.  lor  example,  lm 
session  eslahlishment  and  session  teimmation  Aucbl  lemicls  ate 
1 1 1  si  collected  a!  the  site  u  licit'  lhe\  a  if  cie.iled.  and  then  lhc\  are 
sent  to  the  audil  sue.  I  his  inechanisni  deals  wuh  the  poieiiti.il 
1 .11  lure  ol  the  audit  sue  An  audit  venue  ttatislcis  peiioduallv. 
oi  al  the  revpiest  ol  the  auditor,  audit  mini  malum  to  the  audil 
site  I  he  audit  collection  site  nun  he  changed  1  mm  one  system  to 
anodic  i  by  the  nctvvoik  auditor 

lire  network  aiichlor  is  one  example  ol  the  enhanced  lumlions 
ol  the  trusted  lacilily  maiiagement  of  Sccuie  Xenix  loi  a  sec  me 
nclwoik  I  lusted  piogiains  and  sei vices  me  also  icquiicd  loi  a 
sccuie  netwcuk  opciator  and  loi  a  secure  nclwoik  ndmimslinloi 


I  lie  Inst  c'hg'ctive  is  needed  to  prevent  nclwoik  changes  fi-.im 
invalici.it i ri)i  iliv  senility  rating  ol  Secure  Xenix  I  Ins  objeclne  n 
met  by  placing  all  sec uiily -relevant  network  code  into  device 
clnveis  and  misled  processes.  Ii  allows  aiso  assurance  and 
doc  uinentarnm  loi  ihc  nclwoik  svcuiily  leatmes  lo  lie  provided  in 
an  inciememal  laslnon 

Solivc.ue  w  1 1 1 c  Ii  belongs  to  the  ti  listed  computing  base  musi  he 
cugaiu/ccl  and  siiuciutcd  in  xidi  a  way  that  it  cannot  he 
h\  passed  oi  meddled  in  any  lmaiilhnri/ed  inannei  Netwoik 
nueilacc's  which  would  pmvide  securuv  relevaiu  functions  with 
ijsei  bln  ai  ns.  thc'ieloie.  canuol  he  used  as  no  guaianlee  can  lie 
given  ih. it  an  application  uses  die  piopei  lihi.uy  oi  does  mu 
nnuiilv  the  code  ll  is  also  not  feasible  lo  include  appiu alnms 
with  nclwoik  needs  nun  die  misled  coinpuimg  base  .is  tins  would 
Mihstaiuinliy  mciease  the  assniame  Imnlen  "I  Inis,  die  network 
mletlaces  tnusi  he  prou  der!  by  die  Sccuie  Xenix  kernel  As  the 


addition  o(  system  (.nils  lo  the  kernel  is  not  permitted,  nil  network 
laces  must  lie  implemented  with  psemlo  device  diivers. 

The  network  interlace  ol  Sccuie  Xenix  should  also  be  adaptablc 
In  dillerenl  network  requirements.  Protocol  independence  ol  (lie 
user  visible  interface  is  achieved  v  illi  the  socket  mechanism  jd| 
Sockets  provide  cl i earn  or  datagram  services  between  npplica 
turns,  independent  ol  the  underlying  protocols  used.  A  more 
dilficult  problem  is  to  also  suppoil  network  intereonneelions 
when:  rite  protocols  are  handled  tit  a  front-end  processor.  The 
best  achievable  hete  is  the  placement  ol  all  protocol  processing 
(unctions  into  a  network  daemon  That  way  appropriate  inter 
faces  ana  sohwarc  structures  are  provided  which  can  he  le used 
for  a  host/fi nnt-end  protocol. 

1  he  extensions  ol  the  misled  compming  base  ol  Secure  Xenix 
and  the  striintne  ol  the  set  me  network  facilities  are  shown  in 
f  igure  1  All  protocol  handling  is  done  by  lire  network  daemon: 
ibis  daemon  also  manages  the  address  mapping  between  network 
addresses  and  Fiber  net  addresses.  Packets  received  from  the  trsei 
interlace  arc  wrapped  well  the  appropriate  protocol  headers, 
al fixed  with  n  security  label,  and  sent  to  the  network.  Packets 
received  (torn  the  network  are  unwrapped  ol  llieir  protocol 
headers,  checked  lor  tficir  destination's  security  label,  and 
moved  to  the  destination's  user  interlace. 

Session  management  and  audit  service  arc  also  implemented  as 
daemons.  Session  management  handles  session  setup,  network 
access  authentication,  and  session  termination.  Connection  es 
lahlishtnem  is  also  under  the  contiol  of  the  session  mechanism. 
'I  he  audit  service  audits  session  and  connection  setup  arid 
lerrmnaiton.  It  also  handles  lire  ttansfer  ol  audit  utloimalioii  lo  a 
location  t>[  the  network  auditor's  choosing.  Not  shown  is  the 
network  management  daemon-  It  allows  lor  the  inspection  ol  the 
session  and  socket  control  structures,  and  (or  the  termination  ol 
connections  and  sessions. 


I  he  session  mechanism  icipmcs  dial  all  related  connections  ate 
under  the  control  ol  a  session  Only  processes  within  lire  same 
process  group  which  created  the  session,  therefore,  ate  allowed 
to  establish  connections  belonging  to  that  session  To  cnloicethw 
a  1  lie  handle  associated  with  tin  open  session  is  used  as  ke\ 
when  creating  the  endpoint  ol  a  connection  belonging  ro  that 
session.  I  lie  file  handle  is  inherited  by  all  children  of  the  process 
giotip  thus  allowing  the  establishment  of  additional  connections 
As  a  session  can  be  opened  only  once  this  assures  that  no  piocess 
outside  the  process  group  can  create  a  eonneelion. 

T  lie  actual  implementation  of  the  secure  netwoik  features  is 
earned  out  fot  an  l-Tlicr net  based  network  using  the  fCI'/IP 
piotoc  il  suite  |  5  |  Basic  mechanisms  such  as  sessions,  sockets, 
and  the  network  daemon  are  in  place,  though  at  picscnt  only  the 
GDI’  protocol  is  suppoiled  A  maim  effort  o  still  ici|uired  to 
provide  assurance  lor  the  network  security  [entities. 
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T  li is  paper  describes  a  privilege  control  mechanism  for  the 
UNIX®  operating  system.  The  me  hanism  is  intended  to  satisfy 
the  B2  requirement  of  least  privilege  ,  and  to  provide  fine-grained 
control  over  access  hy  users  to  services  and  objects.  The 
mechanism  is  largely  independent  of  other  security-related 
features  and  is  useful  as  an  incremental  addition  to  a  less-secure 
UNIX. 

The  principal  features  of  this  me'  hanisin  arc 

•  Separate  privilege  sets  to  manage  the  inheritance  of 
privilege  as  distinct  from  the  exercise  of  privilege. 

•  Decomposition  of  the  UNIX  super-user  privilege  into 
distinct  privileges. 

.  Discretionary  privileges  that  can  be  assigned  at  the 
command  level. 

•  A  luidaivmcnt  for  th<  UNIX  setuid  feature  which  ir. 
compatible  with  it  and  can  exist  side-by-side  with  it 

•  Extensible  set  of  privileges.  Users  can  create  trusted 
application;;  which  use  new  privileges  (However,  we 
don’t  discuss  this  aspect  in  this  paper.). 

•  Compatibility  with  standard  UNIX.  The  mechanism  ts 
externally  applied,  so  applications  from  a  non-scrure 
UNIX,  including  most  scluttl  applications,  can  run 
without  being  recompiled. 

Privilege  sets  assigned  to  users,  or  program  files,  or  both  Is  not  a 
new  idea.  It  is  derived  from  the  capability  research  of  the  1970’s. 
For  instance,  file  privilege  sets  were  used  in  KSOS-11^,  and  both 
kinds  of  sets  are  used  in  Digital  Equipment  Corporation’s  VMS®. 
Also,  assigning  privileges  by  command  (discretionary  privileges)  is 
a  feature  (wheel  and  operutor  concepts)  of  HBN's  TliNBX  syst  im. 

The  novel  feature  of  our  privilege  mechanism  is  the  first  item  in 
the  bullet  list  above.  We  will  define  several  privilege  sets  whe  h 
will  interact  to  do  two  things,  impose  a  strict  inheritance  d 
possible  privileges  on  a  process  hierarchy,  and  allow  selective 
activuhon  of  those  privileges  when  a  program  file  is  exe-  uted  or  a 
privilege  is  assigned  at  command  level. 

The  paper  is  organized  as  follows.  The  following  section  is  an 
overview  of  the  privilege  mechanism.  The  remaining  sections 
piovide  details,  examples,  and  implementation  notes  The 
sections  describing  the  privilege  sets  themselves  are  lh<*  heart  of 
the  paper.  There  is  a  section  summarizing  the  privilege  set 
rccomputations  as  done  by  key  system  calls  such  as  fork  and 
excc,  and  a  section  with  security  policy  statements  regarding 
privilege  sets 


OVERVIEW 

The  privilege  control  mechanisms  of  standard  UNIX  are  th| 
sctuid/setgid  and  super-user  features  A  companion  paper 
discusses  the  security  aspects  of  set  aid  and  selgid.  The  1>12 
requirement  of  least-privilege'  demands  a  granularity  of  privilege 
finer  than  no  privilege  and  all  privilege.  Though  the  UNIX  super- 
user  privilege  could  he  represented  in  a  l$2-rated  system  as  a 
single  privilege  implying  all  other  privileges,  a  range  of  privileges 
is  also  required. 

Common  methods  for  conferring  privilege  are:  associating 
privilege  sets  with  use's,  associating  privilege  sets  with  program 
files,  and  doing  both  Associating  privileges  with  program  files  is 
done  in  standard  UNIX  (with  setjugjid  bits  on  a  file )  and  in  a 
number  of  other  systems  including  KSOS-1P  and  VMS. 
Associating  a  privilege  with  an  executable  file  allows  a  user 
access  to  privileged  operations  in  a  restricted  way  —  the  program 
that  uses  the  privileges  is  distributed  with  the  system  and  cannot, 
be  controlled  by  the  user  Other  protection  mechanisms  such  as 
file  piutection  inodes  or  login  environments”  arc  used  to  restrict 
access  to  the  privileged  executable  programs.  (A  disadvantage, 
often  seen  in  practice,  is  that  the  other  mechanisms  (file  inodes  or 
access  lists)  are  relied  upon  for  the  integrity  of  the  executable 
files,  rendering  the  privilege  mechanism  an  extension  rather  than 
an  independent  addition  to  the  overall  protection  scheme.  Our 
privilege  mechanism  is  easily  implemented  with  a  enough 
privileges  to  protect  the  privilege  database  —  for  inntanet,  it 
would  he  a  privilege  to  execute  a  file  with  a  non-empty  privilege 
set.) 

A  central  problem  with  associating  privileges  with  program  files 
is  the  problem  of  controlling  propagation  of  privileges.  In 
standard  Unix,  it  is  possible  for  a  non-privilegcd  user  to  acquire 
privilege  by  executing  a  setuid  file.  In  UNIX  and  ether  systems 
which  associate  privileges  with  users  as  well  as  with  files,  a  user 
may  acquire  a  privilege  not  in  the  user  privilege  set  by  executing 
a  file  with  that  privilege  Our  mechanism  controls  the 
propagation  of  privilege  in  two  ways:  strict  inheritance  of 
possible  privileges,  and  dynamic  recomputat.ion  of  usable 
privileges.  At  login  time,  the  login  process  for  a  user  is  given  a 
set  of  privileges  (a  bounding  set)  associated  with  the  user  that 
contains  all  privileges  that  rould  possibly  be  exercised  by 
processes  in  the  process  hierarchy  determined  by  this  process 
However,  if  these  privileges  were  also  enabled  at  the  time  they 
were  conferred,  the  initial  process  (and  possibly  many  others) 
would  be  greatly  over-privileged.  This  would  not  satisfy  the  \\2 
requirement  of  least-privilege.  We  solve  this  problem  by 
interpreting  this  bounding  set  as  the  set  held  "in  trust"  for 
dependents  The  privileges  cannot  be  executed  just  because  they 
are  in  the  bounding  set  —  something  not  completely  under  the 
control  of  the  process  must  enable  them.  Privileges  are  enabled 
when  a  program  file  is  executed.  A  particular  privilege  becomes 
available  to  a  process  when  the  privilege  is  in  both  the  bounding 


set  of  the  proress  that  executed  the  file  and  in  the  privilege  set 
associated  with  the  file.  Thus,  a  program  file  enables  a  privilege 
already  known  to  the  user  rather  than  granting  a  privilege  new  to 
the  user. 

The  connection  just  described  between  a  bounding  set  that  limits 
a  process  hierarchy  (descended  from  a  login  process)  and  a  file 
privilege  set  associated  with  a  program  file  is  the  novel  feature 
(and  the  most  important  feature)  of  the  privilege  mechanism 
described  in  this  paper.  As  will  be  seen,  this  mechanism  requires 
several  distinct  process  privilege  sets  (recomputed  by  exec  when  a 
program  file  is  cxecu'ed)  in  addition  to  relatively  static  privilege 
sets  associated  with  users  and  program  files. 

An  additional  feature  is  the  ability  of  a  user  to  assign  a  privilege 
to  a  particular  process  executing  a  program  file  rather  than  to 
the  file  itself.  (Privileges  that  can  be  assigned  in  this  way  — 
discretionary  privileges  —  must  also  be  in  the  process  hounding 
set.)  This  feature  is  similar  to  the  wheel  and  operator  concepts 
mentioned  earlier.  This  concept  is  useful  for  security  testing,  or 
for  use  in  a  less-secun  environment,  or  for  use  where  the  UNIX 
super-user  feature  is  desired.  Discretionary  privileges  were  added 
to  the  basic  model  at  the  request  or  our  Real-Time  UNIX  group. 

1  hey  wanted  the  privilege  mechanism  to  control  access  to  certain 
real-time  services  which  can  take  over  or  even  crash  a  system  and 
preferred  to  trust  the  system  programmers  to  use  the  privileges 
with  prudence  during  development.  This  attitude  is  typical  in 
development  environments. 

The  remainder  of  this  paper  describes  our  proposed 
implementation  of  this  scheme  in  detail 


I  opular  usage  of  the  term  privilege  is  sometimes  confusing  One 

It-  ..  ........  I  .  .  .  .  ,  . 

* . .  “  «•**  aucMi  which,  ii  misused, 

could  Violate  the  security  policy  of  the  system.  Thus,  "writing  the 
password  file"  is  a  privilege.  Another  definition  is  that  a  privilege 
is  the  capability  to  perforin  an  operation  which  could  violate  the 
security  policy  of  a  system.  Hither  notion  will  work.  We  adopt 
the  latter  view  in  this  paper  and  define  a  privilege  as  a  relation 
whose  members  are  tuples  of  the  form:  (subject,  mode,  object). 
Thus  one  privilege  might  he  (joncs,  write,  /etc/passwd).  We 
say  very  little  in  this  paper  about  the  encoding  of  privileges  It  is 
sufficient  to  assume  that  privileges  are  mapped  in  sonic  way  onto 
integers.  It  may  even  be  advisable  in  an  implementation  to  map 
mode  and  object  pairs  separately  onto  integers  to  facilitate  the 
assignment  of  subjects  to  niodc-objert  pairs.  Another  conrerii  is 
that  the  concept  of  mode  is  not  a  simple  one.  Some  privileges 
cause  the  disabling  or  particular  security  or  integrity  checks 
rather  than  enabling  a  particular  action.  Overriding  of 
discretionary  access  controls  is  an  example  of  dim.  Privileged 
operations  will  include  operations  such  as: 

•  override  mandatory  access  checks  (security  labels1’) 

>  override  discretionary  access  checks  (file  modes  or 
access  lists) 

«  use  a  particular  system  rail 

•  connect  to  a  particular  port 

•  execute  'a  particular  file 

•  write  a  particular  file 

•  execute  I/O  instructions  directly  (a  real-time  extrusion 

to  UTX/32) 

llic  list  above  is  meant  to  be  representative  rather  than 
exhaustive. 


There  is  an  increasingly  well-known  jargon  associated  with  secure 
computing  systems  We  will  use  the  terms,  trusted  software,  and 
security  policy,  as  defined  in  the  Department  of  Defense  Trusted 
Computer  System  Evaluation  Criteria*.  For  the  reader’s 
convenience,  we  define  them  again  here  (though  somewhat  re¬ 
phrased)  The  security  policy  of  a  system  is  a  statement  of  the 
rules  which  the  system  enforces  in  order  to  both  protect  sensitive 
information  stored  in  the  system  and  to  protect  the  system  itself 
from  penetration  or  unauthorized  modification.  Trusted  software 
is  software  that  is  relied  upon  to  enforce  the  security  policy. 

One  concept  from  standard  UNIX  is  closely  connected  with 
privilege-granting.  In  UNIX,  there  is  a  real  user  id  associated 
with  each  process.  It  is  an  identifier  that  denotes  the  user  on 
whose  behalf  the  process  in  operating  How  closely  this  is  really 
the  case  varies  with  the  version  of  UNIX  being  used,  hi  CJould’s 
secure  UNIX,  IJTX/32S®,  an  extra  id,  the  log  id  is  used  to 
uncquivocably  identify  the  user  responsible  for  a  process 
However,  in  this  paper,  we  wish  to  avoid  using  concepts  specif.* 
to  UTX/32S,  so  we  will  be  content  with  the  real  user  id. 


In  this  section  we  introduce  the  terminology  of  privilege  sets  and 
briefly  indicate  their  interconnections.  There  are  two  kinds  of 
privilege  sets:  those  associated  with  relatively  static  system 
objects  and  those  associated  with  processes.  We  mention  both 
kinds,  however,  those  associated  with  solely  with  processes  will  be 
explained  in  later  sections. 

A  user  bounding  set  is  a  set  of  privileges  associated  wall  a  user 
entry  in  the  system  password  file.  At  login  time,  this  set  is 
associated  with  the  user’s  login  process  as  the  process  bounding 
set  of  the  process  The  process  bounding  set  of  a  process  contains 
all  of  the  privileges  that  can  possibly  he  exercised  hv  that  process 
or  any  descendent  of  that  process.  Having  a  privilege  in  the 
process  bounding  set  does  not  mean  that  the  privilege  can,  in 
fact,  be  used.  Tips  will  be  explained  in  detail  inter.  Another  set 
associated  with  a  user  entry  in  the  password  file  is  the 
discretionary  sc 1  At  login  time,  a  copy  of  the  user’s  discretionary 
sot-  becomes  the  discretionary  set  of  the  process.  The 
discretionary  set  is  a  subset  of  the  user  bounding  set  and  contains 
those  privileges  that  can  be  assigned  to  a  particular  invocation  of 
a  program  file,  as  distinguished  from  being  assigned  to  the  file 
itself. 

Kach  program  file  has  a  file  I  ntnding  set  consisting  of  those 
privileges  that  the  program  is  trusted  to  exercise.  (In  practice, 
most-  program  files  will  have  empty  file  hounding  sets.)  When  a 
program  file  is  executed,  t  hose  privileges  in  l lie  process  bounding 
set  that  are  also  in  the  file  bounding  set  (or  the  discretionary  set) 
are  made  active  and  thus  capable  of  being  used  This  activation 
is  done  by  using  two  other  privilege  sets  that  will  he  defined  later 
—  potential  sets,  and  active  sets  Wo  will  refer  t-o  sets  that  contain 
privileges,  both  those  defined  in  this  section  and  those  defined 
I  *er,  as  privilege  sets. 


A  process  bounding  st  t  :s  associated  with  each  process  The 
process  bound  mg  set  contains  all  of  the  privileges  that  a  process 
and  its  descendents  may  ever  use  It  is  computed  when  the 
process  is  created  and  is  recomputed  if  the  real  user  id  of  tin- 
process  is  changed  The  process  hounding  set  of  a  parent h-ss 
process  (eg,  the  init  process)  is  set  by  the  system  initialization 
code.  After  system  initialization,  no  process  may  add  a  privilege 
to  its  own  process  bounding  set  or  that  of  any  othe  r  process,  hut 
any  process  may  delete  a  privilege  from  its  own  process  hounding 
set  A  login  process  takes  as  its  process  hounding  set  the  user 
bounding  set  of  tie*  u-  r  A  child  process  created  by  fork  inherits 
its  process  bounding  set  from  its  parent.  A  new  prueiw*  image 


formed  by  exec  inherits  its  process  bounding  set  from  the  calling 
process.  If  a  process  has  deleted  members  from  its  process 
bounding  set,  any  descendenl  of  that  process  inherits  the 
diminished  set,  not  the  original  set.  Consequently,  as  one 
descends  the  process  hierarchy,  the  process  bounding  set  may  get 
smaller  but  cannot  get  larger. 

Any  system  call  that  changes  the  real  user  id  of  a  process  causes 
a  recomputation  of  the  process  bounding  set  The  new  process 
bounding  set  is  the  intersection  of  the  old  process  bounding  set 
and  the  user  bounding  set  of  the  ikw  real  user.  A  ( trusted) 
system  cal!  that  changes  the  real  user  id  of  a  process  must  pass 
the  the  user  bounding  set  of  the  new  user  to  the  kernel  so  that 
privilege  set  recomput-ation  can  take  place.  Note  that  even 
though  user  bounding  sets  can  change  during  the  lifetime  ol  a 
process,  a  process  cannot  gain  privileges  from  a  recomputation  of 
its  process  hounding  set  because  the  new  set  is  always  a  subset  of 
the  previous  set. 

DISCRETIONARY  SETS 

The  reason  for  having  discretionary  privileges  is  to  designate 
those  privileges  that  can  be  assigned  to  a  process  when  it 
executes  a  program  file  —  as  distinguished  from  assigning  the 
privilege  to  the  file  itself.  Though  the  program  file  can  be  given 
privileges  directly  by  writing  its  file  bounding  set,  some  privileges 
are  so  awesome  --  or  must  be  turned  off  and  turned  on  so  often  -- 
that  it  is  best  to  require  their  attachment  only  at  the  moment  of 
use.  Also,  in  some  environments,  system  programmers  are  trusted 
to  use  prudence  in  their  use  of  privileges  and  generally  suffer  the 
consequences  themselves  if  they  make  a  mistake.  This  is  the  case, 
for  instance,  when  debugging  a  program  that  exercises  direct  I/O 
(a  real-time  extension  to  Gould's  sta  ndard  UTX/32).) 

Each  user  entry  in  the  system  password  file  has  associated  with  it 
a  discretionary  set  of  privileges.  It  is  a  subset  of  the  user 
bounding  set  in  the  same  entry  A  new  login  process  inherits  a 
copy  of  this  set  as  its  own  discretionary  set  Each  privilege  in  the 
process’  copy  of  the  discretionary  set  has  a  flag  that  indicates  if 
the  privilege  is  turned  on  or  turned  o/J  A  process  may  turn  on  or 
turn  oJJ  any  of  its  discretionary  privileges  at  any  time.  A  process 
with  a  lull  set  of  privileges  in  its  bounding  and  discretionary  sets 
and  all  discretionary  privileges  turned  on,  could  bestow  the  UNIX 
super-user  privilege  to  its  children 

The  discretionary  set  of  a  parentless  process  is  set  by  the 
initialisation  code.  When  a  process  is  created  by  fork  it  inherits 
its  discretionary  set  from  its  parent  process  The  new  process 
image  formed  by  exec  lias  the  same  discretionary  set  as  that  of 
the  calling  process,  however,  exec  turns  ojj  all  discretionary 
privileges  in  the  new  discretionary  set.  (This  is  to  avoid 
accidentally  passing  turned-oil  privileges  to  second- generation 
dcsrendeiits.  Eirst-gcneration  desremirnts  can  lie  passed 
immediately  usable  discretionary  privi’-ges,  as  described  later)  If 
the  real  user  id  of  a  process  is  changed,  the  discretionary  set  is 
set  to  the  intersection  of  the  process  hounding  set  and  the 
discretionary  set  associated  with  the  new  user  id  (again  with  all 
privileges  turned  off). 

We  will  -lluxt.rate  this  mechanism  villi  an  cva.npl.-  in  this 
example,  priv  is  a  (new)  command  internal  to  'he  shell  that 
exists  just  for  the  purpose  of  processing  vlset'i lonai  \  privii-ges. 
A  program  maau_v/rite  does  a  massive  rewnte  of  a  disk  volume 
alii!  for  increased  performance  exec  x  I  e  s  hardware  I/O 
iusli  uct ions  di—  ci.lv.  Any  process  which  dors  i!us  u  list  have  tin 
privilege,  direct_io  A  user  that  lias  direct_io  in  hit.  or  her 
bounding  set  could,  by  typing  the  follsA'i'ig  command,  execute 
mrvRB_writ?  and  temporarily  give  it  the  direct_io  privilege. 

priv  direct_io  rnas8_write 


Priv  executes  a  system  call  that  turns  on  the  discretionary 
privilege  dircct,„_io.  Dircct_io  must,  of  course,  already  he  a 
member  of  the  discretionary  set  of  the  shell  process  that  the  user 
is  communicating  with,  and  this  implies  that  direct — io  is  in  the 
discretionary  set  of  the  user.  When  exec  is  called,  it  does  two 
things  with  regard  to  the  discretionary  set.  It  adds  each  turned- 
on  discretionary  privilege  to  the  potential  set  (defined  later)  of  the 
new  process,  and  it  passes  the  discretionary  set  of  the  calling 
process  to  the  new  process  image  after  turning  off  c ach  privilege 
That  the  new  process  has  the  direct_io  privilege  available  to  .1 
when  it  begins  execution  and  need  not  enable  it  explicitly  follows 
from  the  discussion  in  the  next  two  sections  on  potential  sets  and 
active  sets. 


Each  process  has  associated  with  it  a  potential  set  derived  from 
its  process  hounding  set,  its  discretionary  set,  and  the  file 
bounding  set  of  the  program  being  executed.  The  potential  set 
contains  the  privileges  that  can  be  erercised  by  the  process,  as 
distinct  from  the  privileges  that  can  be  passed  on  by  the  process 
—  the  latter  are  defined  by  the  process  bounding  set.  The 
potential  set  represents  the  combination  of  the  user  and  program 
file  privileges  that  the  executing  process  may  actually  use.  A 
process  may  delete  a  member  from  its  potential  set,  but  may  not 
add  a  member.  The  usefulness  of  the  potential  set  is  apparent 
when  subprocesses  with  few  or  no  privileges  (such  as  a  login  shell) 
are  interposed  between  processes  that  can  exercise  privileges. 

The  potential  set  of  a  parentless  process  is  specified  by  the 
system  initialization  code.  The  potential  set  of  a  new  process 
created  by  fork  is  the  same  as  the  potential  set  of  the  parent 
process.  A  new  login  process  takes  as  its  potential  set  the  file 
bounding  r,ct  of  the  login  program  -  this  will  be  illustrated  later 
in  an  example.  When  the  real  user  id  of  a  process  is  changed, 
potential  set  is  recomputed  as  the  the  intersection  of  the  old 
potential  set  arid  the  recomputed  process  bounding  set.  Thus,  the 
potential  set  is  always  a  subset  of  the  process  bounding  set. 

The  potential  set  of  a  new  process  image  created  by  exec  is  the 
intersection  of  the  process  hounding  set  of  the  process  calling 
exec  (which  is  the  same  as  the  new  process  image's  bounding  set) 
and  the  set  formed  by  the  union  of  the  file  bounding  set  of  the  file 
to  be  executed  and  that  subset  of  the  discretionary  set  consisting 
of  those  privileges  that  are  turned- on.  Note  that  the  new 
potential  set  is  a  subset  of  the  new  process  bounding  set.  This 
reeomputation  does  three  things:  brings  in  the  privileges  of  the 
file  to  be  executed,  allows  discretionary  privileges  to  be  added, 
mid  keeps  the  potential  privileges  within  tin  hounding  privihges. 
This  computation  is  an  extremely  important  part  of  the  privilege 
mechanism  because  it  makes  it-  possible  for  the  privileges  kept  in 
trust,  in  the  process  bounding  set  to  become  available  for  use. 

The  privilege  sets  discussed  up  to  this  point  manage  tin- 
propagation  of  privilege  to  new  processes  1  be  process  bounding 
set  is  an  absolute  bound  lor  a  process  and  all  its  descendetits,  the 
potent  la!  set  bounds  only  the  process  itself;  and  discretionary 
pi iv ileges  are  sw-cteiicis  that  can  be  added  along  the  way  At 
any  point  in  tiim,  the  aefine  set,  described  ill  this  section, 
contains  precisely  those  privileges  that  are  active,  i  e.,  can  he 
■  xrrei:.ed  It  is  always  a  subset  01  the  potential  set.  It-  is  this  set 
that  trusted  code  uses  to  decide  what  privileges  are  available 
when  a  privileged  operation  is  requested. 

The  active  set  facilitates  the  localization  of  privilegf  usage  in 
I  rusted  cotie  Specifically ,  a  p.oeess  may  cluninaK  ell  privileges 
I  rum  its  active  set  before  performing  a  series  ol  unprivileged 
actions,  then  re-in sci t  privileges  from  ns  potential  set  into  Us 
art-ive  set  as  tln-y  are  needed.  Tins  feature  reduces  the  effort  of 
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code  inspection  for  trusted  processes,  and  ^jielps  satisfy  the  least- 
privilege  requirement  in  a  B2-rated  system1  . 

The  active  set  of  a  parentless  process  is  specified  by  the  system 
initialization  code.  When  a  new  process  is  formed  by  a  fork,  the 
active  set  is  inherited  from  the  parent  process,  but  any  process 
may  change  its  active  set,  subject  to  the  general  rule  that  the 
active  set  is  always  a  subset  of  the  potential  set.  When  the  real 
user  id  of  a  process  is  changed,  the  active  set  of  the  process  must 
be  recomputed  since  the  potential  set  is  recomputed.  The  new 
active  s.’t  is  the  intersection  of  the  previous  active  set  and  the 
new  potential  set  When  a  new  process  image  is  created  by  exec, 
the  active  set  is  initialized  to  the  new  potential  set  as  recomputed 
by  exec.  (Thus  we  see  that  when  a  discretionary  privilege  is 
added  to  a  new  potential  set.  by  exec  (as  described  in  the  section 
on  discretionary  privileges),  it  is  also  added  to  the  new  active  set, 
and  thereby  becomes  a  privilege  that  can  be  exercised. 

PRIVII.BG E  COMPUTATION  SUMMARY 

In  the  previous  sections,  each  privilege  set  was  discussed 
individually.  In  this  section,  we  summarize  how  these  sets  are 
computed. 

LOGIN 

The  process  bounding  set  of  a  new  login  process  is  set  equal  to  the 
user’s  bounding  set  in  the  password  file  The  discretionary  set  of 
the  process  is  a  copy  of  the  user’s  discretionary  set  (also  in  the 
password  file).  The  potential  set  and  the  active  set  arc  set  equal 
to  the  file  bounding  set  of  the  program  file  login  The  potential 
and  active  sets  will  be  recomputed  when  the  login  shell  is  exec-ed. 
This  will  be  clarified  later  by  an  example. 

FORK 

Fork  doesn’t  change  any  process  privilege  set.  The  process 
bounding  set,  the  discretionary  set  (and  their  on/off  state),  the 
potential  set,  and  the  active  set  of  the  new  process  arc  identical 
to  those  of  the  parent  process. 

CHANGE. IHtALJISEtLID 

There  may  be  several  system  calls  that  change  the  real  user  id  of 
a  process.  The  rule,  stated  heiow,  applies  when  any  of  these 
system  calls  is  used. 

The  new  process  bounding  set  is  the  intersection  of  the  old 
process  bounding  set  and  the  user  bounding  set  associated  with 
the  new  real  user  id. 

The  new  discretionary  set  is  the  intersection  of  the  new  process 
bounding  set  and  the  discretionary  set  associated  with  the  new 
veal  user  id.  All  discretionary  privileges  in  the  new  discretionary 
set  are  turned  off. 

The  new  potential  set  is  the  intersection  of  the  old  potential  set 
and  the  new  process  bounding  set. 

The  new  active  set  is  the  intersection  of  the  old  active  set  and 
the  new  potential  set. 

EXEC 

The  new  process  bounding  set  is  the  same  as  that  of  the  calling 
process. 

The  new  discretionary  set-  is  the  same  as  that  of  the  calling 
process  except  that  all  privileges  are  turned  ojj. 

The  new  potential  set  is  the  intersection  of  the  new  (same  as  old) 
process  bounding  set  and  the  set  formed  by  the  union  of  the  file 
bounding  set  and  the  set  of  discretionary  privileges  turned  on  in 
the  discretionary  set  of  the  calling  process. 


Tile  new  active  set  is  the  same  as  the  new  potential  set. 

EilMUTiJEQLJGX 

This  section  summarizes  the  security  policy  as  it  applies  to  the 
acquisition  and  exercise  of  privilege  The  policy  has  several 
aspects  each  of  which  is  encapsulated  in  a  separate  statement: 

.  The  kernel  as  well  as  other  trusted  code  is  trusted  to 
deny  a  request  by  a  process  if  the  requesting  process 
docs  not  have  the  appropriate  privilege. 

.  After  system  initialization  is  completed,  no  process  may 
change  a  privilege  set-  associated  with  another  process; 
no  process  may  add  privileges  to  its  own  process 
bounding  set  or  to  its  own  potential  set 

•  If  process  A  is  a  dcscendcnt  of  piocess  II,  then  the 
process  hounding  set  of  A  is  a  subset  of  the  process 
bounding  set  of  B. 

•  For  each  process,  its  active  set  is  a  subset  of  its 
potential  set,  and  its  potential  set  is  a  subset  ot  its 
process  bounding  set. 

•  During  the  lifetime  of  a  process,  the  only  privileges  that 

is  may  use  are  those  in  its  potential  set  —  as  initialized 

at  the  creation  of  the  process. 

•  At  any  point  in  time,  the  privileges  that  can  be 

exercised  by  a  process  are  precisely  those  in  the  active 
net  of  the  process. 

•  When  a  new  process  image  is  formed  in  order  to 

execute  a  program  file,  its  active  set  is  contained  in  the 
union  of  the  file  hounding  set  of  the  file  being  executed 
and  the  discretionary  set  of  the  user- 

-  If  any  file  is  modified,  its  file  bounding  set  is  made 
empty. 

EXTIiNIiEiXEXAMm: 

In  this  section  we  work  through  the  recomputalions  of  process 
privilege  sets  that  occur  as  a  user  logs  onto  the  system  and  types 
a  couple  of  commands  Bach  creation  of  a  new  process  or  of  a 
new  process  image,  each  changing  of  the  real  user  id,  is  indicated 
below  as  a  separate,  numbered  action: 


(1)  init  —  fork-> 

processl 

(2)  processl  — exec— > 

getty 

(3)  gelty  —  cxcc-> 

login 

(4)  login  -sctrcuid-> 

proocss2 

(5)  process’d  ~cxcc-> 

esh 

(fi)  esh  — fork— > 

process^ 

(7)  proccss3  — exec— > 

chmod 

(8)  esh  -priv(8)-fork- 

>  process! 

(9)  processl  --exec—  > 

mass_write 

For  each  numbered  action,  we  will  show  the  privilege  sets  of  the 
resulting  process.  The  reader  should  be  able  to  cheek  the 
recalculation  for  a  particular  step  by  starting  with  the  previous 
privilege  sets  and  applying  the  rule  for  the  action  taken. 


I 
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Instead  of  defining  realistic  sets  of  privileges  (and  explaining 
them),  we  merely  indicate  a  set  of  privileges  as  a  set  of  integers, 
each  integer  being  assumed  to  stand  for  some  privilege,  i  e . ,  [1,2,3) 
is  a  privilege  set  with  privileges:  1,  2,  and  3.  In  one  case,  privilege 
8  (sec  below),  we  do  specify  that  it  stands  for  the  direct_io 
privilege  just  to  be  consistent  with  the  example  presented  earlier 
in  the  section  on  discretionary  sets.  When  a  privilege  in  a 
discretionary  set  is  turned  on,  it  wi’l  have  an  *  beside  it. 

We  now  state  tbc  assumptions  that  hold  before  the  first  action 
takes  place.  We  assume  that  the  process  init  has  the  following 
privilege  sets:  process  bounding  set  =  potential  set  =  active  set 
=  |1, 2, 3, 4, 5, 6, 7 ,8],  and  an  empty  discretionary  set  (remember, 
each  number  corresponds  to  a  privilege,  and  privilege  8  is 
direct_io).  We  assume  that  the  program  file  getty  has  file 
bounding  set  =  [2,3,7],  and  the  program  file  login  has  file 
bounding  set  =  [2,3,5,7|.  We  assume  that  the  setreuid  system 
call  changes  the  real  user  to  that  of  a  user  whose  bounding  set  = 
[3 ,^1,7 ,8 j  arid  whose  discretionary  set  =  |7,8].  We  assume  that  the 
program  file  esh  has  an  empty  file  bounding  set.  I  inally,  we 
assume  that  the  chmod  program  file  and  the  mass_write 
program  file  each  have  a  file  bounding  set  =  [3,4,5)- 

The  recomputed  privilege  sets  after  each  action  are  shown  below. 

(1) 

process  bounding  set  =  [l  ,2, 3,4, 5, 6  7,8] 
discretionary  set  =  |empty| 
potential  set  =  [1,2, 3, 4, 5, 0,7,8] 
active  set  =  11,2,3,4,5,5,7,8] 

(2) 

process  bounding  set  =  11,2,3,4,5,6,7,8] 
discretionary  set  =■  [empty] 
potential  set  —  jS,3,7j 
active  set  =  |2,3,7] 

(•») 

process  bounding  set  =  11,2,3,4,5,6,7,8] 
discretionary  set  =  |empty] 
potential  et  =  |2,3,5,7] 
active  set  =  (2, 3, 5, 7] 

(D 

process  bounding  set.  =  [3, 4, 7, 8) 
discretionary  set  =  17,8] 
potential  sot  =  |3,7] 
active  set  —  ]3,7] 


(5) 

process  bounding  set  —  [3,4,7,8j 
discretionary  set  =•=  [7,S| 
potential  set  =  jempty] 
active  set  =  |oiiipty] 

(0) 

process  bounding  set  =  |3.4,7,8] 
discretionary  set  =  |7,8] 
potential  set  =  [empty] 
active  set  =  [empty] 

(7) 

process  bounding  set.  =  ]3,4,7,8] 
discretionary  set  =  |7,8] 
potential  set  =  |3,1] 
active  set  =  |3,lj 


(8) 

process  bounding  set  =  |3,4,7,8( 
discretionary  set  =  [7,8*] 
potential  set  =  |enipty] 
active  set  =  |emp!y| 

('■>) 

process  bounding  set  =  [3, 4,7, 8] 
discretionary  set  =  |7,8] 
potential  set  —  (3,4,8] 
active  set  =  [3,4,8| 

When  maas_write  exits,  the  parent  sheli  process  (esh)  has 
privilege  sets  as  indicated  lit  step  (5). 

Ann  USER  kxampi.k 

In  this  section  we  will  consider  a  simpler  scenario  than  that  of  the 
preceding  section  Our  concern  is  not  with  how  privileges  are 
computed  but  rather  wilh  how  they  can  be  assigned  The 
application  we  are  interested  in  is  the  administrative  chore  of 
adding  a  new  user  to  the  system.  This  example  is  taken 
UTX/32S,  but  this  interface  to  the  authentication  database  could 
easily  be  implemented  in  any  standard  Unix.  An  administrator 
ext  cutes  a  program  file  add._user  which  is  a  client  for  a  trusted 
server.  That-  is,  the  client  process  connects  to  a  known  socket 
where  a  server  daemon  is  listening  for  requests.  The  daemon 
authenticates  the  user  and  forks  a  process  that  execs  a  program 
file  au_back_end  that  is  not  directly  accessible  to  users.  The 
new  process  image  is  the  dedicated  server  that  actually  carries 
out  the  user  request.  The  administrator  communicates  directly 
with  the  dedicated  server  ana  using  a  menu-like  interface  requests 
certain  changes  to  the  password  file  In  this  example,  a  new  user 
entry  would  be  added  to  /stc/pass'tvd. 

Notice  that  each  separate  action  —  execute  a  client,  connect  to  a 
socket,  execute  a  back-cnd  program  file,  request  a  specific  change 
in  the  password  file  -  are  candidates  for  separate  privileges  that 
can  be  assigned  to  different  user  bounding  sets  or  file  hounding 
sets  in  a  way  deemed  the  best  compromise  between  providing 
security  and  being  user-friendly.  Only  those  administrators 
trusted  to  add  new  users  would  have  the  privilege  in  their  user 
bounding  set  to  execute  the  client  add..user  Only  the  file 
add_uaei-  would  have  the  privilege  in  its  file  bounding  set  to 
connect  to  the  applicable  socket.  The  server  daemon  would  need 
no  privilege  beyond  that  of  binding  to  the  right  socket.  The  file 
au_back_end  would  have  the  privilege  in  its  file  bounding  set  to 
modify  the  passwoid  fib .  The  various  tasks  involved  in 
maintaining  the  password  file  could  be  separate  privileges  in 
order  to  enforce  the  two-person  rule.  For  instance,  there  could  be 
a  privilege  for  entering  a  new  user  entry  and  a  privilege  for 
activating  a  user  entry.  No  administrator  would  possess  both 
privileges. 

It  is  interesting  to  note  that  a  malicious  user  not  privileged  to 
write  privilege  sets  would  be  unable  to  write  a  Trojan-horse 
version  of  add_user  capable  of  affecting  the  password  file  Such 
a  program  —  even  if  executed  by  an  administrator  authorized  to 
add  users  —  would  not  be  able  to  connect  to  the  right  server 
socket  or  be  able  to  write  the  password  file  directly  because  Ihe 
needed  privilege  would  not  be  in  the  file  bounding  set  of  the 
program  file! 


In  this  section  wc  discuss  sonic  implementation  issues. 
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A  surprisingly  small  number  of  system  calls  is  needed  to 
implement  the  privilege  mechanism.  These  calls  are  described 
bclovr.  Access  checks  are  not  fully  delineated,  so  keep  in  mind  the 
restrictions  as  set  forth  in  previous  sections.  The  system  call 
arguments  used  below  —  h,  d,  p,  a,  f  --  represent  the  the  process 
bounding  set,  the  discretionary  set,  the  potential  set,  the  active 
set,  and  the  file  bounding  set,  respectively.  Also,  the  structure 
<pr;v>  is  a  privilege  set  with  an  on/off  flag  for  each  of  its 
members. 

There  are  two  system  calls  for  manipulating  the  privilege  sets 
associated  with  a  process  or  program  file, 

<priv>  =  read_psct(  [b  d  p  a  f)  |  [file]  ) 

Read  one  of  the  privilege  sets  of  this  process  (file). 

ivrite_p8et(  <priv>,  [b  d  p  a  f]  j  [file] ) 

Sets  one  of  the  privilege  sets  of  this  process  (file).  This  call  can 
be  used  to  delete  members  from  the  process  bounding  set,  the 
discretionary  set,  the  potential  set,  and  the  active  set.  It  can 
turn  a  discretionary  privilege  on  or  off.  it  can  add  members  to 
the  active  set  as  long  as  the  active  set  remains  a  subset  of  ihe 
potential  set.  These  are  all  unprivileged  operations.  Modifying  a 
file  bounding  set,  however,  is  a  privileged  operation. 

Inside  the  operating  system  kernel,  many  operations  may  become 
privileged  operations  in  a  secure  system.  In  order  for  the  kernel 
to  determine  if  an  operation  i3  privileged  and,  if  so,  if  the  caller  is 
privileged  to  perform  that  operation,  an  additional  system  call  is 
needed: 

<true/false>  =  haa_priv(  <subjcct  id>,  <access  mode>, 
<priv-id>  ) 

Determine  if  this  subject  may  access  this  object  in  this  mode. 
The  call  fails  if  a  privilege  is  needed  and  the  subject  doesn't  have 

it. 

System  calls  that  change  the  real  user  id  of  a  process  must  pass 
the  applicable  user  bounding  set  to  t he  kernei  so  that  privilege 
recomputation  can  be  done.  The  leason  for  this  is  ttiat  user 
bounding  sets  will  likely  be  stored  in  a  file  instead  of  in  a  kernel 
table.  Of  course,  the  system  calls  in  question  are  privileged,  and 
the  calling  processes  arc  trusted  to  pass  the  correct  information 

As  described  in  the  section  on  discretionary  sets,  a  command 
internal  to  the  shell  (priv)  is  desirable  in  order  to  enable  a 
discretionary  privilege  for  a  new  process. 

Implementing  privilege  sets  as  bit  vectors  is  straightforward 
except  perhaps  for  the  question  of  where  file  iiounding  sets  a.c  to 
be  stored  Assume  for  the  moment,  that  file  bounding  sets  are 
attached  to  inodes  in  the  file  system  U  would  be  desirable  at 
system  startup  to  verify  that  the  file  bounding  sets  on  the  disks 
arc  set  correctly  (c.j;..  that  there  are  no  new  or  modifier! 
privileged  programs).  rIhis  ca.n  be  done  by  shell  scripts  which 
verify  the  contents  of  bounding  sets  for  specific  tiles,  chock  for  t.he 
existence  of  unaiiUiomed  non-empty  bounding  sets,  and  compute 
a  ciyp!  igtaphic  checksum  on  file;;  with  non-empty  bounding  sets 
On  a  small  system,  this  could  be  done  by  an  exhaustive  search  of 
the  file  system.  On  a  large  system,  this  could  be  an  intolerably 
slow  process.  An  a'ternative  method  is  needed.  For  example,  one 
could  store  the  names  of  all  the  privileged  processes,  their  file 
bt  imiTing  sets,  ».*'d  t.heir  file  checksums  in  a  startup  file.  At 
start-up  time,  a  program  using  the  start-up  file  would  install  ii.-e 
file  bounding  sets  by  attaching  them  to  file  inodes  locked  in 
memory.  The  file  bounding  sets  would  never  be  attached  to  disk 


inodes.  An  inode  not  in  this  memory-resident  cache  would  have 
an  empty  file  bounding  set. 

FURTHER  I. SSI  IKS 

The  discussion  of  a  number  of  issues  has  been  deferred  to  other 
papers.  Some  of  these  will  not  be  fully  resolved  until  we  have 
experience  with  this  mechanism  in  a  variety  of  situations.  These 
include: 

•  The  optimal  encoding  of  privilege  vectors.  This  is  an 
important  aspect,  affecting  both  performance  and 
extensibility  of  the  mechanism. 

•  The  enumeration  of  specific  privileges  appropriate  to 
UNIX. 

•  Extensibility  to  user-assigned  privileges. 

•  Use  of  this  mechanism  in  implementing  s  curity  policies 
requiring  fine-grained  integrity  models  in  addition  to 
data  security. 
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AN  OVERVIEW  OF  THE  DoD  COMPUTER  SECURITY  RDT&E  PROGRAM 


Panel  Chairman,  Mr.  Lawrence  Castro 
Chief  of  the  Office  of  Research  and  Development 
National  Computer  Security  Center 


The  purpose  of  this  panel  is  to  inform 
the  audience  of  the  progress  of  and  plans  for 
the  Research,  Development,  Testing,  and 
Evaluation  (RDT&F.)  efforts  sponsored  by  the 
Department  of  Defense  (DoD)  Computer  Security 
Program  (CSP) . 

The  presentation  is  organized  according  to 
the  five  distinct  areas  of  the  R&D  Program: 
Secure  Architecture,  Secure  Database 
Management  Systems  (DBMS's),  Network  Security, 
Modeling  and  Verification,  and  Aids  to 
Evaluation. 

The  first  part  of  the  presentation  will 
allow  each  panel  member  to  describe  the  status 
of  his  area's  current  programs  and  new 
initiatives  for  FYB8.  In  addition,  we  will 
include  a  progress  report  of  the  multilevel 
secure  workstation  program.  Among  the  new 
initiatives  to  be  described  are  those  related 
to  support  of  the  Strategic  Defense  Initiative 
(SDI).  The  participating  panel  members  from 
the  three  military  service  labs  will  describe 
the  support  they  are  providing  to  the  CSP. 
Following  this,  the  panel  will  entertain 
questions  from  the  floor. 

panes!  Mcmhorc; 

CDR  David  Vaurio,  Deputy  Chief, 

Office  of  Research  and  Development 
(R&D),  National  Computer  Security 
Center  (NCSC) 

Mr.  Wayne  Weingaertner ,  Office  of 
R&D,  NCSC,  Secure  Architectures 

Dr.  John  Campbell,  Office  of  R&D, 

NCSC,  Secure  DBMS 

Mr.  George  Stephens,  Office  of  R&p, 
NCSC,  Network  Security 

Mr.  Rob  Johnson,  Office  of  R&D,  NCSC, 
Modeling  and  Verification  and 
Aids  to  Evaluation 

Mr.  II.  Lubbes,  Space  and  Naval 
Warfare  Systems  Command 

Mr.  John  Faust,  Rome  Air  Development 
Center  (KADC) 

Mr.  John  Prcussc,  Army  Communica¬ 
tions  and  Electronic  Command 
(CECOM) 

TIIE  STRATEGY 

The  DoD's  CSF  is  aimed  at  a  quantum 
increase  in  the  security  of  America's 
automated  information  systems.  Toward  this, 
the  National  Computer  Security  Center  (NCSC) 
has  begun  an  aggressive,  three-pronged  R&D 
strategy.  Its  first  major  goal  is  to  improve 
the  security  of  current  systems.  Secondly, 


the  Center  will  encourage  the  development  of 
now  products  using  known  technologies  and 
finally  will  encourage  new  technology  R&D . 

The  Computer  Security  RDT&E  Program 
addresses  the  first  priority  by  providing  the 
means  to  test  various  security  options  or 
features,  such  as  authentication,  labeling,  or 
auditing.  For  the  second  part  of  the  strategy, 
the  RDT&E  program  provides  the  technological 
support  needed  to  achieve  an  "Al"  class 
system,  as  defined  in  the  DoD  Trusted  Computer 
Systems  Evaluation  Criteria.  This  includes 
stabilizing  and  improving  verification 
environments,  providing  background  material 
for  refining  security  models  used  in  the 
development  of  Al  systems,  and  finally, 
developing  Al  demonstration  systems 
themselves.  The  third  phase  of  the  strategy, 
i.e.  going  beyond  Al  and  transferring  research 
breakthroughs  into  marketable  products, 
depends  entirely  on  the  RDT&E  Program. 

RESOURCES 

The  Computer  Security  RDT&F,  Program  is  a 
cooperative  undertaking  led  by  tlie  NCSC  with 
the  participation  of  the  Army,  Navy,  Air 
Force,  Defense  Communications  Agency,  and 
Defense  Intelligence  Agency.  Beginning  with 
the  FY84  budget,  DoD  RDT&F  funds  for  computer 
security  were  consolidated,  centralizing  the 
program  but  permitting  decentralized 
execut ion. 

The  FY88  program,  ar  in  the  previous 
years,  provides  specific  funds  to  be  spent  b> 
the  several  DoD  components.  Consolidation,  as 
prescribed  in  DoD  Directive  5215.1  (the 
Computer  Security  Evaluation  Center,  October 
25,  1982),  avoids  unnecessary  duplication 
among  DoD  components;  while  decentralized 
execution  takes  advantage  of  the  scarce 
expertise  needed  to  provide  technical 
oversight  of  contracts  dealing  with  the  highly 
technical  field  of  computer  security. 

PROGRAM 

To  meet  the  challenge  of  transferring 
research  breakthroughs  into  marketable 
products  most  effectively,  wo  have  channeled 
our  efforts  into  five  distinct  areas:  secure 
architectures,  secure  database  management 
systems  (DBMS's),  network  security,  modeling 
and  verification,  and  aids  to  evaluation. 

These  five  subprograms  explore  particular 
aspects  of  computer  security  research  and 
development  and,  when  combined,  provide  a 
solid  program  spiraling  past  the  state  of  the 
art  and  into  new  technological  frontiers. 

Secure  Architecture 
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Secure  architecture  addresses  the  design 
and  implementation  cf  trusted  computing  bases 
(TCB's).  A  TCI!  is  the  hardware  and  software 


mechanism  in  a  computet  system  that  enforces 
security.  Our  current  thrust  is  to  push  the 
edge  of  technology  for  TCB's  by  investigating 
kernel-based  systems.  Security  kernels  are 
the  classical  means  of  providing  security  in  a 
TCB.  They  are  a  portion  of  the  operating 
system  that  run  in  their  own  domain,  separate 
from  the  normal  operating  system  code, 
intercepting  any  operation  that  has  security 
relevance . 

The  prolific  growth  of  office  automation 
and  personal  computer  (PC)  equipment  and 
software  within  the  Federal  Government  is 
another  area  of  research  concern.  Little 
consideration  has  been  given  to  the  security 
aspects  of  these  stand-alone  and  netted  office 
automation  systems.  Nonsecure  PC's,  for 
example,  negate  the  security  provided  by  even 
the  highest  rated  host  because  labels  used 
within  secure  computers  that  indicate  the 
security  level  of  the  data  be  lost  once  data 
is  transferred  to  a  PC.  Security  enhancement 
will  be  targeted  at  next-generation  PC's  since 
many  of  the  current  generation  systems  are 
single-  state  machines  and  cannot  support 
security. 

Security  enhancement  of  existing 
commercial  systems  is  a  near-term  solution, 
tinder  this  task,  we  are  incorporating  security 
into  the  UNIX  System  V. 

Advanced  security  architecture  work 
provides  new  and  different  architectures  for 
secure  computers.  The  current  effort  in  this 
dLeu  is  the  Logical  Coprocessing  Kernel 
(LOCK) . 

The  LOCK  takes  a  novel  approach  towards 
providing  security  in  that  it  incorporates  a 
separate  security  processor.  (The  LOCK  effort 
is  the  subject  of  a  separate  paper  of  this 
conference . ) 

Placing  the  security  mechanism  in  a 
separate  processor  has  notable  advantages  over 
the  kernel-based  approach.  The  kernel  is  open 
to  attack  because  its  architecture  shares 
security-related  portions  of  the  system  with 
non-security-related  parts.  A  separate 
security  processor,  however,  prevents  a  user 
process  from  accessing  the  security-relevant 
portions  of  the  system. 

A  by-pcoduct  of  security  processors  is 
improved  performance,  because  they  remove  the 
security  processing  load  from  the  main 
processor.  The  initial  design  phase  of  the 
computer  should  be  available  in  1988. 

Secure  Database  Management 

Multilevel  database  management  security 
R4D  has  received  far  less  attention  than 
secure  operating  systems.  In  the  summer  of 
19b2,  the  Air  Force  and  the  National  Science 
Foundation  cohosted  a  workshop  of  experts  in 
DBMS  to  examine  the  security  problem.  Three 
recommendations  resulted: 

‘provide  near-term  relief,  which  is 
desperately  needed  and  is  achievable; 


‘for  the  mid-term,  develop  working 
demonstration  of  high-leverage  applications; 

and 

‘conduct  long-term  research  in  the 
theoretical  and  practical  foundations  of 
secure  multilevel  DBMSs. 

Although  current  and  planned  programs  have 
made  some  progress  towards  achieving  these 
goals,  there  has  been  no  breakthrough  that 
substantially  improves  DBMS  security. 

The  Secure  DBMS  subprogram  focuses  on 
protecting  databases  and  their  related 
components.  It  is  comprised  of  three  research 
areas:  trusted  prototypes,  studies  and 

analyses,  and  advanced  DBMS  architectures.  An 
effort  to  secure  an  existing  DBMS  entitled 
MISTRESS  is  now  under  way.  Researchers  are 
conducting  various  DBMS  studies  and  analyses 
with  the  following  objectives: 

‘data  dependencies  --  to  achieve  a  family 
of  multili  el  secure  DBMSs; 

‘evaluation  --  to  investigate  t lie 
evaluation  ramifications  of  DBMS's; 

‘sanitization  --  to  examine  the  downgrading 
and  upgrading  of  multilevel  data  in  database 
systems . 

Another  study  is  being  conducted  of  the 
integrity  lock  technique.  This  crypto¬ 
graphically  seals  information  stored  in  an 
automated  system,  with  the  objective  of 
incoi porating  this  technique  directly  into 
computer  architectures  supporting  multilevel 
secure  DBMS  operations.  Finally,  the  LOCK 
will  be  used  to  develop  a  trusted  DBMS 
application. 

Network  Security 

Network  security  focuses  on  the  protection 
of  data  while  it  is  being  transmitted  between 
host  computers  and  users-  A  data 
communications  environment  has  been  created 
between  geographically  dispersed  computers 
that  includes  networks  of  computers,  terminals 
attached  to  computers  that  are  attached  to 
networks,  and  the  internetting  of  multiple  and 
various  combinations  of  these  systems. 

Current  computer  networking  technology  has 
concentrated  on  providing  services  in  a  benign 
environment,  and  the  security  threats  to  these 
networks  have  been  largely  ignored.  While 
literature  abounds  with  examples  of  hackers 
wreaking  havoc  through  access  to  public 
networks  and  the  computers  connected  to  them, 
hackers  have  exploited  only  a  fraction  of  the 
vulnerabilities  that  exist.  Techniques  need 
to  be  developed  that  will  prevent  both  passive 
exploitation  (eavesdropping)  and  active 
exploitation  (alteration  of  messages  or 
message  routing) . 

To  reduce  these  vulnerabilities,  we  have 
initiated  research  in  the  development  of 
components,  high-level  applications  such  as 
distributed  processing,  multilevel  mail  and 
file  transfer,  modeling,  and  advanced 
architectures.  Within  the  arer  of  advanced 
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architectures,  we  are  conducting  internet 
research,  device  authentication  studies,  and 
architectural  simulation.  The  challenges 
facing  us  in  the  network  security  field  are 
boundless.  (The  results  of  our  network 
modeling  work  will  be  presented  at  another 
session  of  this  conference.) 

The  NCSC  hopes  that  coordination  within 
the  Federal  Government  and  a  sound  R&D  program 
will  enable  it  to  work  witti  industry  to  create 
a  line  of  network  security  systems  that  meet 
the  needs  of  the  Federal  Government. 

The  problems  of  introducing  computer 
security  into  tho  Ada  programming  language  are 
being  investigated.  Ada  is  the  DoD-mandated 
programming  language  for  mission-critical 
systems.  We  are  developing  verification 
environments  to  be  integrated  into  Ada 
software  development  systems  as  well  as  a 
suite  of  secure  protocols  in  Ada  to 
demonstrate  how  to  marry  these  two 
technologies.  (A  special  session  devoted  to 
these  developments  is  a  part  of  this 
conference . ) 

Evaluation  Aids 

Our  Aids  to  Evaluation  subprogram 
addresses  the  need  to  streamline  and  improve 
the  system  evaluation  process.  We  believe  we 
can  make  the  evaluation  process  more 
responsive  to  our  national  demand  for  computer 
security  requirements  throughout  the  system's 
life  cycle,  identifying  bottlenecks, 
automating  tools  to  simplify  the  evaluation 
process,  evaluating  the  effectiveness  of 
safeguards,  and  reducing  subjectivity  in  risk 
assessment.  We  are  involved  in  research  on 
intrusion  detection  evaluation  tools  and 
techniques,  erasure  and  emergency  destruction, 
risk  management  and  generic  product 
eval uation . 

Modeling  and  Verification 

Modeling  and  Verification  explore 
conceptual  solutions  to  computer  security 
problems  (model ing)  and  provide  assurance  that 
system  spec i f icat ions  or  implementations  are 
consistent  with  the  model  (verification).  RsD 
in  modeling  and  verification  addresses  a 
critical  need  for  trusted  software  and 
hardware  systems  of  high  reliability.  To 
extend  the  state  of  the  art  in  security 
modeling  and  verification  approaches,  we  have 
embarked  on  rive  research  endeavors:  Ada 
verification,  integrated  design  and 
verification  environment,  security  modeling, 
software  verification,  and  hardware  and 
firmware  verification.  Our  ultimate  research 
goal  is  to  verify  systems  at  all  levels  of 
design  and  implementation. 
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ABSTRACT 

The  Federal  Government  is  the  largest  single  producer,  consumer, 
and  disseminator  of  information  in  the  United  States! 1).  since 
government  information  is  itself  a  commodity  often  with  economic 
value  in  the  marketplace.  Federal  departments  and  agencies  are 
required  to  certify  the  protection  of  their  automated  information 
systems  (AIS)  that  house  sensitive  information.  Various 
government  regulations  and  standards  have  only  minimally 
described  the  certification  process.  Also,  the  manpower  and 
money  needed  to  make  certification  meaningful  are  scarce  and 
reside  primarily  in  special  technical  organizations. 

This  paper  addresses  certification  in  management  terms,  provides 
examples  of  certification  in  everyday  life,  and  examines  ways  to 
maximize  the  use  of  national  resources  and  policies  to  achieve  a 
certified  AIS  application. 


CERTIFICATION  in  everyday  life 

Life  is  full  of  risks.  Most  of  us  enjoy 
taking  a  risk  every  once  in  a  while,  whether 
that  means  a  career  change,  a  stock 
investment,  or  a  bet  on  the  Daily  Double. 
Many  risks,  though,  are  transparent  to  us. 
To  illustrate  this  transparency  let's  examine 
a  typical  weekday  morning  for  most  Americans. 
To  get.  us  through  the  day  some  of  us  will 
take  vitamins,  others  valium,  some  both.  A 
cup  ot  coffee  often  is  next  for  most  "red- 
blooded"  Americans.  And  half  of  the 
population  dabbles  in  the  fine  art  of  make-up 
application  before  leaving  the  house.  Now, 
we  don't  stop  to  think  about  whether  the 
vitamins  or  valium  are  safe  to  swallow,  the 
coffee  grounds  are  pure,  and  the  cosmetics 
are  safe  to  apply.  Instead,  we  disregard 
such  thoughts  because  we  entrust  the  quality 
of  consumer  goods  to  those  whose 
responsibility  it  is  to  ensure  the  safety  of 
such  products.  The  mission  of  the  U.S.  Food 
and  Drug  Administration  (FDA)  is  to  enforce 
laws  and  regulations  that  protect  the 
consumer's  health,  safety,  and  pocketbook [ 2 ] . 
The  "Federal  Food,  Drug,  and  Cosmetic  Act"  is 
tho  basic  food  and  drug  law  of  the  United 
States  to  assure  the  consumer  that  food  is 
wholesome  and  safe  to  eat;  that  drugs  are 
safe  and  effective  for  their  intended  use; 
and  that  cosmetics  are  safe  and  made  from 
appropriate  ingredients.  We  trust  the  FDA  to 
certify  that  products  are  safe.  For  instance, 
coffee  imported  into  tho  United  States  is 
inspected  for  infestation,  mold,  and 
contamination,  and  if  found  objectional,  tho 
cargo  is  refused  entry.  Vitamins,  valium, 
and  cosmetics  are  also  protected  under  the 
Act  against  misbranding  or  adulteration. 
Because  the  FDA  enforces  rigorous  regulations 
to  protect  consumers,  the  FDA's  approval  of  a 
product  assures  us  of  its  safety. 


Like  the  FDA,  the  Public  Health 
Department  enforces  regulations  to  ensure  a 
clean  and  healthy  environment  in  public 
places.  Before  facing  tho  work  day,  some 
of  us  might  stop  at  a  diner  or  fast  food 
restaurant  for  breakfast.  Most  restaurants 
today  maintain  high  standards  of 
cleanliness  not  only  due  to  Health 
Department  regulations,  but  also  because 
tho  public  will  not  tolerate  dirty,  insect- 
infested  eateries.  Tho  procedures  to 
maintain  a  healthy,  pleasant  atmosphere 
remain  transparent  to  the  customer  since 
much  of  the  maintenance  is  performed  after- 
hours  or  behind-the-scenes.  The  restaurant 
owner  relics  on  the  Health  Department's 
certification  to  assure  the  public  of  a 
healthy,  safe  environment  and  also  to 
continue  business. 

Although  we  will  probably  not 
jeopardize  our  lives  by  drinking  coffee, 
wearing  lipstick,  or  eating  an  "Egg 
MacMuffin,"  we  do  risk  adverse  reactions  if 
any  of  these  products  are  not  inspected  or 
prepared  properly.  They  are  all  vulnerable 
to  either  accidental  or  malicious 
tampering,  whether  performed  by  people, 
insects,  or  machines.  Automated 
information  systems  (AIS)  are  also 
vulnerable  to  accidental  or  malicious 
tampering  which  could  cause  unsafe 
operations.  The  vulnerabilities  could 
present  unacceptable  risks  fo  computer 
applications  which  require  protection  of 
its  sensitive  information.  .lust  like 
vulnerabilities  in  consumer  goods,  AIS 
vulnerabilities  must  also  be  managed. 


CERTIFICATION  of  an  AIS 

Now  the  AIS  is  becoming  a  part  of 
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a  recipient.  If  SDNS  uses  X.420  message  body  part 
definitions  incorporating  security  labeling 
provisions,  SDNS  [-Mail  components  can  check  this 
intra-PDU  information  against  the  clearances  of 
intended  recipient  as  indicated  in  their  certificates. 

4.6  IDENTITY  BASED  ACCESS  CONTROL 

E-Mail  t BAC  Hcterini riat ions  will  be  based  on  a 
process  involving  X.400  0/R  names  and  certificate 
ID  fields  identifying  users.  Orange  Rook  require¬ 
ments  for  individual  accountability  (imposed  at  C2 
levels  and  above)  underscore  the  need  for  user 
identification  at  the  granularity  of  named 
users  or  groups  of  named  users. 

User  identification  quantities  can  be  checked 
against  data  structures  constraining  the  set  of 
users  to  whom  a  given  user  is  authorized  to  send 
secure  mail.  It  would  be  convenient  for  I BAC 
checking  purposes  if  the  0/R  name  format  is  used 
for  user  identification  within  certificates  as 
well;  if  the  formats  are  different,  an  endpoint  UA 
must  be  able  to  translate  between  0/R  name  format  and 
the  form  used  in  certificates.  An  originator 
must  be  able  to  select  an  appropriate  recipient 
certificate  based  on  the  recipient  0/R  name  in  an 
outbound  message,  and  a  recipient  must  be  able  to 
select  an  appropriate  originator  certificate  based 
on  the  originator  0/R  name  in  an  inbound  message. 

As  0/R  names  are  hierarchically  qualified,  it 
seems  useful  to  provide  analogous  hierarchic  qualifi¬ 
cation  for  IBAC  features,  for  example,  it  could  be 
appropriate  to  grant  a  particular  user  the  rinht  to 
send  mail  to  anyone  in  organization  A  (without 
needing  to  exhaustively  enumerate  all  members  of 
organization  A),  as  well  as  to  user  C  (and  user  E 
alune)  within  organization  B. 

b.  LAYLR  2 

5.1  INTRODUCTION 

The  SDNS  access  control  provides  for  automatic 
PAA  which  authorizes  the  association  and  therefore 
communications  between  poors  to  exist.  The  SDNS 
also  provides  for  PAE  while  the  connection  exists. 
SDNS  security  services  at  OSI  Layer  2  can  employ 
these  procedures  to  allow  unattended  information 
processing  equipment  to  establish  a  conmunications 
channel  and  communicate  according  to  locally 
accredited  security  policies. 

The  data  link  layer  uses  the  raw  transmission 
facilities  provided  by  the  physical  layer  and 
transforms  it  into  a  conmunications  circuit  that 
appears  to  be  error  free  to  the  layers  above. 

Layer  2  functions  include  error  detection,  error 
correction,  retransmission  and  flow  control.  The 
data  link  layer  may  offer  several  different  classes 
or  qualities  of  service  to  the  network  layer 
depending  on  different  performance  and  cost 
parameters . 

5.2  ACCESS  C0NTR0L_ SERVICES  AT  LAY I R_2 

The'SDNS  provides  a  wide  variety  of  security 

services,  at  Layer  2  the  SDNS  can  provide  access 
control,  authentication  and  confidentiality  to  the 
entities  represented  by  the  PESDIJ.  Therefore,  a 
layer  2  SDNS  security  component  can  deliver  security 
services  to  data  ccmmunicat ions  equipment  at  a 
level  of  granularity  associated  to  the  PISDU. 

The  data  link  layer  is  highly  dependent  on  the  media 
or  physical  layer,  requiring  differing  PISDU  coding 
techniques  and  frame  definitions  in  order  to  provide 
the  Layer  2  services  mentioned  above.  Therefore, 
the  conf idential tty  services  and  implementations 


provided  by  the  SDNS  security  component  must  vary 
with  the  differing  medias  being  serviced.  In 
addition,  the  SDNS  defines  the  protocols  necessary 
to  support,  the  higher  layers  in  order  to  perform  the 
PAA  process;  however,  the  layer  2  protocols  must 
be  media  dependent  and  in  many  cases  remain  outside 
the  SDNS  standard. 

5.2.1  Layer  2  PAA.  Toe  Peer  Access  Approval  process 
binds  the  peers  at  each  end  of  the  data  link  with 
Enforcement  Vectors  (EV)  which  contain  the  allow¬ 
able  range  of  security  attributes  and  identities 
with  which  each  peer  is  allowed  to  communicate.  The 
PAA  also  binds  the  TEK  and  the  maximum  allowable 
association  lifetime  into  the  EV.  The  PAA 

process  is  similar  to  PAA  process  at  higher  OSI 
layers  with  differences  associated  predominantly 
with  what  the  peer  entities  represent.  The  Layer  2 
PAA  uses  the  following  tier  processes: 
o  Global/Partition 
o  National  RBAC 
o  Local  RBAC 
o  Local  IBAC 

As  with  access  control  security  policies  at 
other  layers,  the  local  administrations  use  the 
SDRS  security  mechanisms  to  define  the  policy  for 
secure  information  transfer  at  Layer  2  as  well. 

The  PAA  process  results  in  an  TV  that  contains 
the  following  SDNS  security  attributes  and 
identities  for  layer  2. 

o  Global/Partition  identifier 
o  I  oral  Authority  Name 
o  Compartment  oi  Levels 
o  IBAC  (Address  or  Name) 

5.2.2  Lay ei'  2  P,AE .  The  Peer  Access  Enforcement  is 
limited  to  the  level  of  granularity  determined  by 
the  PLSDU  and  will  not  monitor  security  labels 

at  this  layer.  However,  the  PAL  process  must 
control  the  following  functions  within  the  security 
component: 

o  Val id  EV 
o  TEK  Seloi  tion 
o  Cryptographic  Resync 
o  Cryptographic  Integrity 
o  TEK  Timeout 
o  EV  Destruction 

The  security  component  for  a  Layer  2  device 
nornally  allows  a  single  data  link  to  exist  and 
therefore  a  single  association  to  exist  for 
the  PAE  process  to  maintain.  However,  this 
restriction  is  unnecessary  and  a  single  SDNS 
security  component  could  support  link  layer 
multiplexing. 


171 


AN  GVERVILW  OF  TIIL  CANEWARE  PROGRAM 


lk']  bol  t  L.  Rogoi  s 
National  Security  Agency  -  Cb 
Ft.  Meade,  MO.  20799 


1.0  INTRODUCTION  - 

The  National  Security  Agency  is  currently 
involved  in  several  programs  to  hasten  the 
day  when  high-quality  communication:-, 
security  can  be  effectively  and  efficiently 
provided  for  computer  networking 

applications.  A  very  promising  development 
in  this  arena  is  a  program  called  CANEWARE. 
It  is  the  purpose  oi  this  paper  to  present 
an  overview  of  CANEWARE  functionality.  The 
paper  looks  at  CANEWARE  from  the  point  -of- 
view  of  its  system  capabilities;  it  docs  not 
probe  the  internals  of  its  hardware  and 
software  .  The  CANEWARE  program  is  being 
performed  on  contract,  with  Motorola  Inc,, 
Government  Electronics  Group.  Operational 
equipment  will  be  available  in  1990. 

2_._0  WHAT  IS  CANEWARE  - 

CANEWARE  is  a  development  program  to  provide 
high  performance  security  services  for  host 
computers  on  long  haul  packet  switched 
networks.  CANEWARE  will  facilitate  military 
grade  information  security  ( INFOS EC)  by 
performing  host.-to-host  encryption  of 
packets  and  by  enforcing  both  mandatory  and 
discretionary  access  control  policies.  The 
principal  equipment  elements  are  the 
CANEWARE  Front  End  (CEE)  a  .d  the  CANEWARE 
Control  Processor  (CCP)  .  The  CFE  protects 
host  data  on  the  network  by  encryption, 
ensures  that,  hosts  send  and  receive  data 
only  at  authorized  security  levels,  and 
enforces  "need-to-know"  security  policies  on 
all  data  exchanges  between  hosts  .  The 
CANEWARE  Control  Processor  maintains  the 
"need-to-know"  data  base  and  distributes 
those  permissions  to  the  CPE's,  performs 
network  security  audit  function:-.,  and 
provides  centralized  administrative  control 
and  monitoring  .  CANEWARE  is  targeting 
compatibility  with  the  family  of 
systems/cqu ipment  that  implement  the 
standards  of  the  Secure  Data  Network  System 
(SDNS)  .  SDNS  is  a  separate  NSA  program  to 
specify  an  Open  System  Interlace  (OSl) 
standard  architecture  for  a  wide  variety  ol‘ 
data  networks  including  Packet  Switched 
Networks  (TSII's)  and  Local  Area  Networks 
(LAN's).  In  an  SDNS  related  program,  NSA  is 

developing  a  Key  Management  Center  (KMC) 
that  will  generate  and  distribute  FlKtl’l.Y- 
bnsed  key  material  .  CANEWARE  will  utilize 
this  facility  as  .its  source  ol  key  material 
and  authcr.t i cated  privileges. 

3.0  THE  APPLICATION  - 

CANKWARE's  primary  application  is  X  .29 
PSN '  s  .  The  DDN  Standard  Service  X  .29  is 
being  implemented  .  A  modular  software  and 
hardware  design  allows  modification  to 
accommodate  other  protocols.  The  full  range 
of  security  services  can  be  provided  lor  a 
single  PSN  or  across  a  concatenation  of 
PSN '  s  (a  catanet)  .  DOD's  Internet  Protocol 
(IP)  is  fully  supported  .  The  serviced 
nctworks/catanets  ir-y  be  cither  Red  or 


Black  .  For  example,  the  "host"  may  be  a 
gateway  to  a  Red  LAN.  CANEWARE  will  support 
network  applications  with  up  to  lu  Domains 
per  system;  where  a  Domain 
users  that  is  served  by  a 
redundant,  pair).  Each  CFE 
base  on  up  to  1000  crypto 
keys,  address  information, 
etc . ) . 


is  a  community  of 
single  CCP  (or  a 
can  retain  a  data 
connect i ons  ( i  .  e 
security  levels, 


4 . 0  FUNCTIONALITY  - 

The  principal  security  services  that 
CANEWARE  provides  are: 

*  Encryption/decryption  of  all 

user  data 

*  Mandatory/Piseret ionary  Access 

Control 

*  Authenticat ion  of  ail  hosts 

*  FIREFLY  key  management 

*  Multi-level  security 

These,  and  other  functions,  are  summarized 
in  the  following  paragraphs: 

Host -To-llost  Encrypt  ion- CFE ' s  provide  host- 
to-host  encryption  of  eat  a  between 
authorized  host  pairs.  Traffic  encryption 
keys  are  generated  via  a  FIREFLY  exchange 
and  shared  only  by  a  pair  of  communicating 
hosts  .  Encryption  is  by  an  approved 
algorithm  implemented  in  compl ranee  with  the 
requirements  of  NSA's  Functional  Security 
Requirements  Spec  i  f  icat  i  on  .  Tmpor.t , 

Security  Fault  Analysis  (SEA),  and  Anti- 
Tamper  speci t icat ions  are  satisfied. 
CANEWARE  is  being  designed  to  be  C0MFUS1 C 
certified  at  the  It?  level  of  the  "Orange 
Book"  .  This  requires  a  rormal  Security 
Policy  Model  and  the  development  of  a 
Trusted  Computing  Base  (1CM). 

Key  Management  -  An  outstanding  lealute 

of  the  CANEWARE  approach  ir.  that  it  is 
ottering  the  first  implementation  of  1IREIEY 
key  management  techniques  tot  data  net  wot  ks. 
This  is  the  approach  being  pionotod  by  t  he 
SDNS  initiatives  .  FIR1.M.Y  evolved  1 1  on 
public  key  technology  and  is  used  to 
establish  pair-wise  trattic  encryption  keys 
lor  the  subsequent  encryption  ot  data  . 
FIREFLY  key  material  will  be  obtained  uun 
an  external  Key  Management  Center  (KMC), 
which  NSA  will  establish  to  provide  keying 
material  for  futuie  secure  data  networks  . 
The  FIREFLY  material  obtained  Iron  the  KMC 
will  contain  the  identification  oi  the  CM 
and  that  of  its  attached  host  .  It  will  also 
include  a  listing  of  recur  it y  levels, 
compartments,  and  other  privileges 
authorized  for  the  ho:  .  The  OKE-to-CH. 
FIREFLY  exchange  will  provide  a  mutually 
unforgeable  identification  and  an 
enumeration  ot  security  clearances  between 
communicating  CPE's  .  FI  Rill Y  keying 

material  will  be  ordered  through  controlled 
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everyday  life  and  of  course  bringing  along 
with  it  associated  vulnerabilities  and  risks. 
Managers  of  MS  resources  must  be  prepared  to 
face  risks  of  disclosure,  modification,  and 
non-availability  of  their  information.  Files 
that  were  once  kept  private  within  the 
conf'nes  of  a  physical  office  space  arc  now 
vulnerable  to  uncontrolled  access.  Managers 
responsible  for  AIS  resources  need  conf idence 
that  reasonable  assurances  (or  acceptable 
levels  of  risk)  are  ap;lied  to  AIS  resources. 
And,  if  and  when  a  vu 1 ner an i 1 1 t y  is  exploited 
maliciously  or  -ccidently,  the  ma  lager  wants 
to  turn  to  someone  who  can  explain  why  it 
happened.  Just  as  in  everyday  life,  managers 
need  tin'  best  information  available  to 
establish  confidence  and  accountability  in 
business  operations. 

For  federal  AIS  managers,  providing 
reasonable  assurances  for  the  protection  of 
.'IS  resources  is  essential  to  assuring  the 
integrity  of  federal  operations.  Federal 
managers  are  required  by  law,  the  Federal 
Managers'  Financial  Integrity  A  c  t  I  3 ]  ,  to 
provide  reasonable  assurances  for  federal 
resources.  Coni idence  and  accounlab i 1 i ty  are 
required  for  the  proto r.ion  ol  federal 
resources  from  fraud,  waste,  ami  abuse.  Not 
arbitrary,  this  policy  is  looking  out  for  the 
true  owners  of  federal  resources  -  the 
public.  The  office  of  Management  and  budget 
(OMB)  Circular  A-123,  "Internal  Control 
Systems  1 4 ), "  implements  this  law.  A-123  is 
an  interna!  controls  regulation  that  sets  in 
motion  .1  process  Lu  1  i  £h  rOuf  ioenco  and 

accountability  in  the  protection  of  federal 
operations  from  fraud,  waste,  and  abuse.  To 
achieve  this  process,  A  - 1  2  1  requires 
management  control  plans  based  upon  such 
actions  as  vulnerability  asscssnent.'., 
personnel  performance  agreements,  and  annual 
letters  to  Cm.jicss  stating  w  h  e  t  h  ?  r 
reasonable  assurances  are  being  applied. 

OMll  Circular  A  -  1  3  d  ,  Management  of 
Federal  Information  Resources! 5) , "  is  a 
separate  regulation  that  establishes 
requirements  for  the  efiective  and  efficient 
management  of  federal  information  resources. 
This  regulation  is  the  f recut ivc  Branch's 
response  to  sever..!  i  nf  ormat  ion-re  1  a  ted  laws 
including  l  he  Paperwork  Reduction  Act,  the 
Privacy  Act,  and  cl,e  Freedom  ol  Information 
Ac  t  . 

A  -  1  1 also  requires  that  all  a  g  e  ru:  y 
i n f  o i m a  t i o n  systems  possess  a  level  of 
security  commensurate  with  the  sensitivity  ot 
the  information  and  also  commensurate  with 
the  risk  and  haim  that  could  result  I  run 
improper  operation.  Furthermore,  the  manager 
whose  program  an  information  system  supports 
is  responsible  and  accountable  lot  the 
products  of  that  system. 

More  specifically,  Appendix  III  of  A-II0 
roouires  that  Federal  agencies  establish  AIB 
security  programs  to  safeguard  sensitive- 
information  processed  h  y  -.heir  AIS.  T  li  i  s 
Appendix  requires  an  AIS  security  program  to 
consist  of  four  parts:  applications  security, 
personnel  security,  information  technology 
security,  and  a  secui  i  ty  training  .  n .! 
awareness  program.  As  part  of  applications 
security,  an  appropriate  "agency  official" 
shall  certify  all  sensitive  A'S  sa  f  ?guat ds 


based  upon  the  appropriateness  determined 
by  risk  analysis,  a  design  review,  and 
system  testing.  Periodic  reviews  are 
required  to  preserve  the  integrity  of 
previous  AIS  certification  decisions.  The 
periodic  reviews  not  only  serve  as  a 
security  requirement,  lut  also  as  a 
necessary  way  of  preserving  the  investment 
of  previous  certification  decisions. 

The  relationship  among  the  OMB 
Circulars  is  sometimes  overlapping. 
Assuring  effective  and  efficient 
information  resources  management  is  a 
requi-mnent  that  supports  the  reduction  of 
want'  and  abuse.  However,  pursuing 
effective  and  efficient  AIS  operations  can 
produce  high  risk  to  the  AIS  resources. 
For  instance,  organizing  all  files  into  a 
common  AIS  daca  base  may  be  more  effective 
and  efficient,  but  the  risks  to  privacy, 
fraud,  and  abuse  may  be  significantly 
higher.  Consequently,  continuous 
coordination  is  required  among  those 
responsible  for  implementing  the  Circu' ts. 

Fundamental  to  both  effective  and 
efficient  operations  and  secure  operations 
is  the  security  program  outlined  in 
Appendix  JTI  of  A-130.  Appendix  III  serves 
as  a  security  requirements  tool  for  the 
rest  of  A-130  and  A-123.  It  also  serves 
the  internal  control  needs  of  0MB  Circular 
A  -  1 2  7  ,  "Financial  Management  Systems [5] ," 
which  establishes  a  program,  to  assure  the 
i  n  t  g  •  j  t  i  t  y  of  f  odor  u  1  fino  nc  i  3 !  rr^3  ri3  *5  onion  t 
systems.  Consequently,  a  credible 
certification  statement  is  fundamental  to 
responding  to  federal  regulations. 
Certifying  the  confidence  at.d 
accountability  of  the  protiution  provided 
to  AIS  resources  is  a  basis  for  many 
manage  meat-approval  processes. 
Certification  is  also  a  fundamental  tool 
for  the  managing  of  federal  operations 
where  sensitive  information  is  processed  by 
an  AIS.  This  management  view  demonstrates 
the  growing  dependency  of  implementing 
various  internal  control  laws  and 
regulations  oil  AIS  security  certification. 
It  also  shows  that  a  meaningful 
certification  decision  requites 
coordination  between  management  and 
tochn  cal  communities  within  a  Federal 
agency. 

Viewing  AIS  certification  as  a 
fundamental  management  tool  also  shows  how 
important  the  completeness  del  integrity  of 
technical  information  supporting 
certification  decisions  must  lie.  Gathering 
complete  and  consistent  information  fot 
certification  decisions  is  difficult  work 
a  no  often  requires  the  service.,  of 
technical  specialists,  Gather’ng  both 
technical  and  busi  aoss-or  ieiited  information 
involves  much  analysis  to  identify, 
understand,  and  control  the  vulnerabilities 
and  throats  to  the  AIS  and  its 
application(s)  iri  question.  With  the 
mandate  to  federal  information  resources 
managers  to  make  information  systems  more 
efficient,  reliance  on  complex  technical 
A. IS  controls  make  simple  AIS  certification 
decisions  unlikely.  A  fully  documented  and 
informed  certification  decision  would 
include  analyzing  and  controlling  the  ATS 
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from  a  p  p  ]  i  ca  t  i  on  lj  software  and  operating 
systems,  to  microcode  and  hardware  throughout 
the  AIS  development  and  life  cycle.  Lesser 
documented  and  informed  certification 
decisions  increase  the  risk  of  insecurity 
while  at  the  same  time  threatening  the 
investment  made  to  reach  the  certification 
dec  i  s ion . 

The  ongoing  system  development  and  life 
cycle  of  the  AIS  and  AIS  applications 
provides  the  best  opportunitv  to  acquire  the 
best  AIS  technical  information.  This 
information  is  needed  for  consideration  of 
technical  decisions  whether  they  are 
security-  or  ope ra t i ona 1  - r el  a t ea .  Ideally, 
the  AIS  should  he  built  to  specific  security 
requirements.  Independently  developed 
security  features  added  on  to  an  AIS  present 
the  potential  for  additional  vulnerabilities 
and  risks  if  such  features  are  not  consistent 
with  the  objectives  of  the  system  being 
augmented  (see  reference  6  ;  -  The 
relationship  between  the  AIS  and  add-on 
features  is  easier  to  understand  and  control 
when  adding  some  features  such  as 
cryptograp'-ic  processes  to  the  AIS 
communication  subsystem.  Other  times  it  is 
harder  to  understand  and  to  assure  control  as 
when  adding  an  access  control  package  to  a 
particulai  operating  system.  Since  most 
federal  managers  have  no  control  over  the 
development,  and  life  cycle  of  commercial  AIS 
resources,  they  can  only  accept  what  the 
commercial  market  can  provide,  often  times 
adding  on  security  features. 

Specifying  appropriate  security 
safeguards,  assuring  thit  they  arc  ptoperly 
designed,  asset  inj  that  their  implementations 
ale  adequately  tested  to  meet  their  design, 
and  assuring  that  they  make  sense  in  the 
context  of  the  entire  AIK  is  a  critical 
process.  If  qualified  and  experienced 
personnel  are  not  involved  with  such 
undertakings  and  a  comprehensive  approach  to 
safeguards  is  not  taken,  thin  the  resources 
spent  on  acquiring  the  safeguards  may  have 
been  wasted. 

Given  all  the  technical  and  management 
complexities  in  acquiring  the  best 
information  lor  a  certification  judgment, 
there  should  be  a  njmocr  ol  thoughts  that  run 
through  a  senior  information  resources 
manager’s  mind  when  planning  a  cor t i f icat ion 
p-ogram  for  his  or  her  MS  resources.  Some 
thoughts  to  consider  if  you  arc  a  manager 
follow: 

How  much  resources  should  I  coma.it  to 
this  problem?  A  National  Bureau  of  Standards 
(MBS)  I’  u  t)  1  i  c  a  t  i  o  n  ,  Ovetv  ’  ?  w  of  C  omp  u  t  e  r 
Security  Certification  a  n d  Accreditation , 
notes  that  full  organizational  commitment 
must  exist  for  the  training  and  support  of  a 
security  [  t  o  e .  a  m  to  perform  credible 
certification  analysis.  Unfortunately, 
budgeting  for  an  activity  that  doesn’t  show  a 
tangible  return  is  hard  to  justify.  After 
all,  even  if  ii  were  certified  based  upon  the 
best  information,  that  wouldn't  necessarily 
prevent  something  "had"  from  happening.  And 
even  if  you  do  budget  for.  a  certification 
analysis,  there  is  n.>  guarantee  that  it  will 
survive  the  various  levels  of  a  federal 
budget  process. 


flow  many  technical  security  experts 
and  AIK  resources  does  my  organization  need 
to  implement  a  meaningful  AIS  security 
program  based  upon  credible  certification 
deci si  one? 

How  much  continuous  security  education 
and  what  types  of  security  education  do  my 
personnel  need  to  make  my  AIS  s-curity 
program  credible?  Do  I  have  to  support  a 
crew  of  cryptographers  and  secure  operating 
system  engineers? 

How  often  must  I  exert  th.  necessary 
resources  to  make  my  AIS  security  program 
cred ibl e? 

Does  .my  organization  have  the 
resources  t  repeat  a  ce r t  i  f i ra t i on  process 
for  600  computers  scattered  across  the 
country  that  have  similar  but  different 
app 1 ica  Lions? 

And,  if  I  can't  make  my  AIS  security 
program  credible  do  I  stop  push i n  j  the 
efficiency  of  my  AIS  resources'?  Or  do  I 
push  forward  and  accept  mote  risk? 

The  federal  AIS  manager  who  must  think 
about  these  quest  ions  must  also  have  the 
best  information  available  to  make 
intelligent  decisions.  This  information  is 
hard  and  expensive  to  get  without  help.  In 
fact,  it  .t.  a  y  be  impossible  to  get  ... 
without  help. 

So,  an  .MS  man  i  p*r  ’  s  1  e ve i  of  'ii a t  j i  i r y 
is  tested.  The  renowned  beh.vv  i or ist  David 
McClelland  claims  in  Ills  book.  Power :  t  h-  • 
Inner  K  x  p  c  r  ion  c  e  ,  that  managers  are 
mot  vatej  by  the  need  to  influence  and  that 
a  mat  me  munajer  can  apply  influence  in 
butii  personal  and  social  w  ay  s  1  7  1  vitn 
social  influences  Dein;  the  most  effective. 
Tms  requites  the-  AIS  T.an.i  |er  to  articulate 
comm. in  objectives  and  recognize  her  or  fits 
limitations  in  fulfilling  those  common 
ohjt  rt  i  v«-s  . 

This  means  boeominj  a  team  player. 
AIS  Handlers  must  look  for  teammates  that 
complement  each  other  in  pursuit  of  group 
objectives.  Together  the  teammates  will 
provide  the  means  to  an  end.  How  does  a 
AIS  manager  find  tier  or  ft  l  s  teammates? 

first,  knowing  your  strengths  and 
v  ea  k  tie.-  -  -  •  is  -  start.  By  dividing  AIS 
securi  hloms  into  manageable  portions, 

an  AI.  >e  viewed  as  a  collection  o! 

var  tot;  .  orients,  some  ol  which  may  be1 

o  v  e  t  1  a  p ,.  .  .i  g  .  The  AIS  components  ~  o  u  1  d 
include  technical  components  (computers), 
terminals,  modems,  communications  systems) 
as  w  e  1  I  as  n  o  tt  -  t  e  c  h  n  r  o  a  1  components 
(operator,  security  manager,  pr  icedures, 
app 1  i u J t i ons ,  and  user)  .  The  components  may 
be  described  as  application  types  of 
components  (parts  ordering  systems, 
financial  systems,  law  ct.forcemrnt  systems, 
data  base  syst  ems )  .  A  1  so ,  an  AIS  sei u r i t y 
program  can  be  divided  into  various 
components.  Appendix  III  of  A-llfl  states 
certification  consists  of  risk  analysis, 
security  specifications,  design  reviews  and 
testing.  When  considering  the  various  AIS 
and  AIS  sccutitj  cunpottcnls,  a  manager  can 
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view  whal  can  be  affordably  and  directly 
controlled  under  a  AIS  security  program  and 
what  can  not. 

Expressing  these  components  in  a  common 
language  is  another  important  step.  It  is 
becoming  increasingly  important  for  AIS 
managers  to  be-  familiar  and  active  with  the 
various  standards  communities,  especially  the 
industrial  standards  community  since  they 
potentially  have  the  greatest  commercial 
effect.  Even  though  standards  tend  to  allow 
for  some  broad  interpretations,  often  tc 
accommodate  existing  investments,  and  even 
though  they  take  a  long  time  to  mature,  they 
nevertheless  provide  a  means  of  communicating 
app  1 1  cat i ons  as  well  as  technical  details  in 
a  common  language.  Various  American  National 
Standards  Institute  (ANSI)  anil  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE) 
standards  are  helping  AIS  managers  describe 
the  technical  functioning  of  various  AIS 
components  in  a  language  that  promotes 
consistency  of  those  functions.  Various 
standards,  including  ANSI  XI  financial 
service  standards  and  ANSI  X 1 2  business  data 
interchange  standards,  are  providing  a  common 
way  to  describe  or  specify  security  features 
as  a  part  of  everyday  business  transactions. 

By  surveying  the  standards  market  the 
manager  can  toll  which  standards  apply  to  his 
or  her  components.  Consideration  cf  a 
standard's  relevance  to  an  Air>  app  1  i  ca  t  i  on  ( s ) 
is  important.  So  is  consideration  of  the 
means  to  validate  e  O  m  n  1 ignee  with  the 
standard.  Although  validation  of  security 
standards  is  not  enough  to  claim  that  the 
standards  implementation  is  secure,  it  is  a 
useful  step  in  screening  implementations  that 
claim  to  meet  the  standards  that  may  not. 

Standards  and  standards  validati  in  are 
dlfterent  from  evaluations.  Standards  are 
broad  requirement  statements  of  security 
features,  sometimes  with  enough  options  to 
make  validation  feasible  only  it  a  subset  of 
options  are  validated.  Evaluations  are  more 
implementation  s  pec  i  f  i  c  .  The  Federal 
Communications  Commission  provides  evaluation 
suppett  for  some  communications  compont nts. 
Underwriters  Laboratories  provides  evaluation 
support  lor  some  non-technical  components 
such  as  fire  extinguishers.  The  ii.  a  na  g  e  r 
should  consider  the  national  evaluation 
programs  as  the  team  player  who  assures 
imp  1 emen t a t i on  d'  tails  are  consistent. 


IlOW  NATIONAL  RESOURCES  CAN  HELP  THE  MANAGER 

Just  as  managei s  should  use  standards  to 
help  define  their  security  requirements,  they 
should  also  make  use  of  the  national 
resources  which  evaluate  various  subsystems' 
compliance  with  particular  standards.  There 
are  three  national  resources  addressed  below; 
two  of  the  resources  evaluate  and  end  irsu  or 
certify  subsystems,  while  the  other  only 
evaluates  subsystems.  The  difference  between 
evaluated  and  endor sed/cer t i f l ed  products  is 
subtle  to  the  managei  certifying  the 
app! ications.  AIS  subsystems  that  are 
evaluated,  but  not  certified  place  more 
accountability  on  the  user  of  the  product  and 
the  management  of  the  product's  vendor. 


The  manager  should  recognize  that,  the 
certification  of  her  or  his  AIS  application 
may  rely  upon  similar  but  isolated 
certifications  of  the  AIS'  subsystems  or 
shared  systems.  For  example,  the  AIS  may 
include  an  operating  system,  a  data  base 
system,  an  access  control  system,  an 
encryption  or  authentication  system,  an 
entire  computer  system  or  networks.  Those 
national-level  programs  will  evaluate  or 
certify  various  subsystems  that  the  manager 
might  want  to  consider  as  part  of  his  or 
her  AIS  application.  But  these  various 
subsystems  supporting  an  AIS  application 
must  have  common  security  objectives. 
Consequently,  managers  must  ensure  that 
common  security  requirements  and  standards 
are  required  for  each  subsystem.  The 
evaluation,  endorsement,  and  certification 
programs  described  below  are  available  to 
the  manager  and  are  sponsored  by  the 
National  Computer  Security  Center  (NCSC), 
the  National  Security  Agency  (NSA) ,  and  the 
U.S.  Department  of  the  Treasury. 

Under  the  Commercial  Products 
Evaluation  Program,  the  NCSC  performs 
computer  security  software  and  hardware 
product  evaluations  on  commercial  security 
products.  The  NCSC  does  not  certify  these 
products,  but  does  place  those  products 
that  ai'ot  evaluation  requirements  on  the 
NCSC's  "Evaluated  Products  List  (EPL)." 
Managers  can  "shop"  off  the  EPL  and  be 
assured  that  these  products  have  been 
extensively  evaluated.  The  standard  the 
NCSC  uses  is  tlie  Trusted  Computer  System 
Evaluation  Criteria  (also  known  as  and 
referred  to  hereon  as  the  "Orange 
Book") |8J .  Vendors  can  opt  to  have  their 
products  evaluated  at  different  levels  of 
security  such  as  discretionary  access 
protection,  controlled  access  protection, 
mandatory  protection,  structured 
protection,  and  verified  protection.  Each 
level  of  security  guarantees  certain 
protection  features.  For  example,  if  the 
NCSC  evaluates  an  access  control  system  and 
it  meets  the  Orange  Book  requirements  at 
the  level  of  controlled  access  protection, 
the  manager  can  be  assured  that  the  system 
will  include  the  following  features:  audit 
trail  capabilities,  object  reuse,  user 
identification  and  authentication,  and 
discretionary  access  control.  The  types  of 
subsystems  that  the  NCSC  has  evaluated  so 
far  under  this  program  include  operating 
systems  and  add-on  packages  such  as  access 
control  systems.  The  NCSC  estimates  that 
to  evaluate  a  product  at  the  controlled 
access  protection  level  of  security 
requites  four  people  working  a  qjarter  of 
their  time  fot  one  year  or  one-man-year. 
The  man  years  increase  as  does  the  level  of 
secutity  in  the  product.  Two  man-years  is 
the  estimated  time  required  for  structured 
protection,  which  includes  all  security 
features  in  the  lower  levels  and  also 
mandatory  access  control,  labeling,  and  the 
reference  monitor  concept  in  the  operating 
system , 

For  those  vendors  who  would  rather  not 
commit  to  a  full-scale  evaluation,  the  NCSC 
sponsors  a  Subsystem  Evaluation  Program  in 
which  the  vendor  selects  the  security 
features  it  wants  evaluated.  For  example. 
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a  vendor  can  request  a  product  evaluation  of 
access  control  or  object  reuse  capabilities 
instead  of  committing  to  a  full- scale 
evaluation.  Products  that  have  been 
evaluated  under  the  Subsystem  Evaluation 
Program  are  special  purpose  products  such  as 
user  identification  and  authentication 
devices.  Products  from  both  of  these 
evaluation  programs  provide  a  cost-effective 
way  for  managers  to  choose  their  subsystems 
according  to  their  security  needs.  Another 
program  that  not  only  evaluates  but  also 
endorses  devices  is  sponsored  by  the  NSA. 

N S A  sponsors  the  Data  Encryption  Standard 
(DES)  Endorsement  Program,  also  known  as  the 
Federal  Standard  1027  Program.  Over  the  past 
ten  years  NSA  has  endorsed  over  35  DES 
products  for  both  voice  and  data 
applications.  Managers  who  require  such 
devices  can  choose  from  a  variety  of 
manufacturers  to  suit  their  needs.  NSA  has 
decided  to  phase  out  the  DES  Endorsement 
Program  and  will  no  longer  accept  new 
products  for  evaluation  and  certification 
after  January  1988.  In  replacement  of  the 
DES  Endorsement  Program  and  also  to  foster 
new  business  relationships  with  the  U.S. 
telecommunications  industry,  NSA  began  its 
Commercial  COMSEC  Endorsement  Program  {CCEP) 
in  1985.  The  objective  of  the  CCEP  is  to 
provide  a  widespread  availability  of  quality, 
inexpensive,  secure  telecommunications 
systems  for  use  by  both  the  U.S.  Government 
and  the  private  sector.  The  products 
developed  through  the  program  will  employ 
N S A-pr opr i et a r y ,  classified  cryptography. 
Tne  implementation  of  this  cryptography, 
however,  will  result  in  unclassified 
products.  Vendors  can  design  products  for 
use  to  secure  classified  information  or  for 
use  to  secure  unclassified  only  information. 
So  far,  various  large  and  small  corporations 
have  signed  37  contracts  with  NSA  to  design 
secure  products.  Four  products  have 
undergone  endorsement,  which  is  the  final 
phase  of  the  CCEP  before  production. 

NSA  has  given  one  exception  pertaining 
to  the  DES  Endorsement  Program;  NSA  will 
continue  to  support  DES  devices  for  financial 
applications  under  the  U.S.  Department  of  the 
Treasury's  Electronic  Funds  Transfer  ( EFT) 
Certification  Program  for  Authentication 
Devices.  NSA  stated  in  a  memorandum  to 
Treasury,  "We  agree  ...  with  continued 
Treasury  certification  of  DES  equi[ nent  until 
transition  to  new  cryptographic  technology  is 
possible."  NSA  also  stated  it  will  continue 
to  support  Treasury's  program  with  technical 
guidance  and  assistance.  In  addition  to  the 
technical  expertise  NSA  provides  to  the 
program,  the  National  Bureau  of  Standards 
(NBS)  also  plays  a  role.  A  more  detailed 
description  of  how  Treasury’s  program  can 
benefit  the  manager  follows. 


TREASURY  INITIATIVES  TO  IMPROVE  THE 
CERTIFICATION  PROCESS 

The  U.S.  Department  of  the  Treasury  has 
revised  its  AIS  security  program  to  make  AIS 
security  more  affordable,  simple  and 
meaningful  for  all  of  Treasury's  twelve 
bureaus.  Treasury  has  made  certification  the 
end  that  risk  analysis  and  security 


specification's  design  reviews  and  system 
testing  serve.  At  the  same  lino  it  has 
begun  a  management  study  to  determine  how 
AIS  certifications  can  best  serve  the  other 
management  control  processes.  Treasury's 
strategy  for  improving  the  AIS  security 
program  is  to  use  existing  industry 
standards  and  evaluation  programs  to 
maximize  tne  cos t-bc ne f i t s  to  Treasury's 
AIS  security  program,  while  acquiring  cost- 
effective  AIS  security.  Treasury's 
cont  inuing  involvement  and  commitment  to 
the  ANSI  and  federal  standards  processes 
represents  an  investment  in  the  future 
development  of  standards  that  satisfy 
Treasury's  operational  and  security  AIS 
needs . 

Treasury's  initiatives  begin  with 
departmental  policy.  Several  policy 
decisions  have  partitioned  the  AIS  security 
program  resource  problem  into  manageable 
parts.  The  first  policy  is  Treasury 
Directive  85-01,  entitled,  "Information 
Systems  Secur i ty l 9 ) , "  which  simply  defines 
three  categories  of  information - 
classified,  sensitive  unclassified,  and 
public  -  that  can  be  processed  by  a 
Treasury  AIS.  This  break-out  provides  a 
high-level  framework  to  determine  minimum 
levels  and  types  of  safeguards  needed  for 
each  category  of  Treasury  information. 

The  second  Treasury  Directive,  TO  85- 
02110],  deals  specifically  with  sensitive 
unclassified  AIS  information.  Tl)  85-02 
defines  Treasury's  Automated  Information 
System  Security  and  Risk  Management  Prog  tarn 
as  required  by  OMB  A-130,  Appendix  III. 
This  directive  establishes  acceptable  risk 
for  the  department  in  terms  of  the 
implementation  of  minimum  security 
requirements.  The  policy  and  its 
associated  handbook  is  a  product  based  upon 
the  coordinated  input  of  all  twelve 
Treasury  bureaus  and  the  advice  and 
guidance  of  the  NCSC.  The  bureaus  will 
base  their  AIS  security  programs  on  these 
mini  mums.  Because  of  the  varying 
sensitivity  oi  AIS  resources  and  the 
availability  of  AIS  security  program 
resources,  some  of  Treasury's  bureaus  will 
choose  to  do  more  than  the  minimum. 
Meanwhile,  the  baselines  provide  a  focus 
for  the  AIS  security  program;  a  basis  foi 
AIS  security  education,  risk  analysis, 
security  specifications,  design  reviews, 
and  security  testing. 

The  minimum  security  requirements  are 
based  upon  existing  standards.  The 
standards  chosen  include  controlled  access 
projection  (the  "c2"  level  of  security  as 
defined  in  the  Orange  Book)  for  computer 
security;  and  NSA-approved  cryptography  for 
data  communications,  whether  DES-based  or 
CCEf'-based  cryptographic  products.  Besides 
making  technical  security  sense,  those 
standards  wore  chosen  because  they  also 
provide  a  management  tool  to  i educe  the  AIS 
security  program  costs  to  obtain  a 
meaningful  certification.  This  is  due  to 
the  fact  that,  as  mentioned  earlier,  NSA 
and  NCSC  experts  have  evaluated  the  AIS 
subsystems  by  reviewing  the  design  and 
testing  the  implementations  of  the 
respective  standards.  Moreover  from  an  A  f  .5 
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security  program  perspective,  tiiese 
evaluations  make  up  a  continuing  program  of 
configuration  control  assuring  that 
participants  in  the  evaluation  programs 
maintain  tho  security  for  the  life-cycle  of 
the  product.  AJ though  there  are  never  any 
guarantees  that  careful  design  and 
evaluations  will  fully  remove  the 
vulnerabilities  or  that  the  commercial 
participants  will  fully  comply  with  the  MSA 
or  NCSC  programs,  if  there  is  a  problem, 
there  are  national  resources  and  national 
programs  to  help. 

A  third  policy  position  applies  to  a 
specific  AIS  application  -  Electronic  Funds 
Transfers  (EFT)  .  In  1  984  Treasury  began 
developing  a  policy  on  EFT  Security.  It  was 
determined  that  the  best  existing 
countermeasure  was  authentication  in  lieu  of 
encryption  due  to  the  international  scope  of 
the  requirement.  ANSI  X9.9,  "Financial 
Institution  Message  Authentication,"  was 
selected  as  the  standard.  Treasury's  EFT 
policy,  entitled,  "Electronic  Funds  and 
Securities  Transfer  Policy  --  Message 
Authentication  and  Enhanced  Secur i  ty  (  1 1 )  ,  " 
requires  that,  all  Federal  Government  K  FT 
transactions  be  protected  using  message 
authentication  by  June  1988. 

The  Department  established  an  EFT  Task 
Force  composed  of  representatives  from 
diverse  government  agencies  to  develop 
criteria  for  certification  of  authentication 
devices.  The  criteria  is  based  upon  industry 
standards  including  ANSI  X9.9,  ANSI  X9.1V  on 
key  management.  Federal  Standard  1027  (DBS), 
and  An  S I / 1  EKE  829  Standard  for  Software  Test 
Documentation.  The  criteria  were  published 
in  May  19  8',  and  have  been  sent  to  ever  290 
interested  parties  and  corporations.  Since 
then,  through  Treasury's  EFT  CerLil  cation 
Program  for  Authentication  Device  >,  the 
Department  has  boon  working  with  v  irious 
vendors  to  guide  them  through  the  development 
of  devices  to  meet  the  certification 
criteria. 

Treasury  certified  its  first  device  in 
Jun“  1986  and  is  currently  working  with 
several  more  vendors  who  are  developing 
authentication  devices.  The  Department  is  in 
the  process  of  expediting  implementation  of 
EE  I’  authentication  on  its  financial  systems. 
Treasury  received  n  a  t  i  o  n  a  1  resource 
assistance  in  this  certification  program  by 
signing  a  Memorandum  of  Understanding  with 
NSA  and  NKS.  NHS  agreed  to  provide  s  if, port 
in  validating  compliance  with  various 
security-related  standards.  This  has 
included  ANSI  X9.9,  ANSI  X9 . 1 7 ,  the  Data 
Encryption  Standard,  and  software  engineering 
s  l  <i  n  il  ii  nl  s  ,  Of  course,  NSA  security 
evaluation  support  is  mandatory  because  no 
one  else  in  the  Government  has  their 
ex  pel t i su  . 

Treasury  has  r  e  i  m b  u  r  s  e  d  NHS  for 
developing  automated  val  idation  systems  to 
validate  vendor  compliance  with  ANSI  X9.9  and 
ANSI  X9.17.  At  this  time,  NHS  has  completed 
the  ANSI  X9.9  automated  validation  systems 
for  Treasury  and  is  expected  to  complete 
portions  of  the  ANSI  X  9  .  1  7  automated 
validation  systems  by  the  end  of  the  year. 
Thus  fat,  eight  vendors  have  completed  the 


automated  validation  of  their  products' 
compliance  with  ANSI  X9.9,  one  vendor 
product  has  been  certified  for  Federal  use, 
and  three  others  have  entered  Treasury's 
program  for  certification. 

So,  Treasury  will  make  certification 
decisions  on  EFT  authentication  devices 
based  upon  the  best  information  available 
from  the  results  of  standards  evaluations 
and  implement,  ation  evaluations.  These 
certified  products  will  bo  a  basis  for 
certifying  the  EFT  applications  implemented 
on  federal  AIS.  Federal  managers  of  EFT 
functions  will  have  a  tool  that  will  reduce 
their  security  program  expenses  of 
complying  with  A-130,  Appendix  III.  Moving 
up  the  federal  internal  controls  ladder, 
these  certified  AIS  applications  will 
provide  Federal  agencies  a  basis  for 
assurance  that  their  financial  systems 
comply  with  the  objectives  of  A-123  and  A- 
127  as  well  as  will  provide  tho  basis  for 
more  effective  and  efficient  processing  of 
financial  information  by  removing  much  of 
the  current  paper  flow.  Of  course,  this 
doesn't  totally  remove  federal  agency  AIS 
internal  controls  responsibilities  where 
EFT  is  processed.  Proper  administrative 
internal  controls  such  as  separation  of 
duties  must  be  factoied  in' o  those  systems. 

If  other  AIS  applications  exist  on 
those  systems  that  have  sensitive 
information  to  be  processed,  a  certified 
.".It  subsystem  exists  on  the  system  that  can 
used  to  assure  data  integrity  and  possibly 
confidentiality  as  well  as  user 
accountability.  The  Consolidated  Data 
Network  ( COM)  is  Treasury’s  effort  to 
provide  effective  AIS  services  to  its 
bureaus  throughout  the  i  >untry.  The  CI)N 
will  be  a  totally  encrypted  DES  network, 
which  will  make  it  the  largest  encrypted 
data  system  in  the  civil  Federal 
Government .  It  will  grow  to  be  the 
Department's  secure  data  communications 
utility. 

The  network  is  currently  being  link- 
encrypted  using  NSA-ondorsed  DE.S  devices. 
As  eno-to-onrj  types  of  protection  become 
available,  they  will  reduce  much  of  the 
security  product  needs.  As  enh.anced  key 
management  technologies  become  available? 
and  are  implemented,  whether  ANSI  X9.17  or 
other  techniques.  Treasury’s  security  and 
operational  costs  will  improve. 

Hut,  again,  there  is  good  news  for  the 
various  AIS  applications  such  as  tax 
processing,  revenue  collection,  law 
enforcement ,  payroll,  personnel  and  many 
other  Treasury  AIS  applications.  They  have 
another  certified  AIS  component  at  the i r 
service  and  another  tool  to  base  AIS 
certification  decisions  on  without  spending 
a  lot  of  resources  designing,  and  testing 
cr y o t og r aph i c  safeguards.  Although  CON 
will  not  provide  all  the  protection  that 
some  users  might  need  in  the  near  term,  a 
focus  for  their  AIS  planning  to  address 
those  other  security  needs  is  provided  for 
t  horn . 
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CONCLUSION 


Transfer  Polity  —  Message  Authentication 
and  Enhanced  Security,"  October  3,  1985. 


To  make  an  intelligent  certification 
decision  the  AIS  manager  needs  the  best 
information  available.  -  That  involves 
gathering  both  technical  and  business- 
oriented  information  to  make  a  cost- 
effective  decision.  The  resources  for  this 
information  are  scarce  or  out  of  the  direct 
control  of  most  AIS  managers.  On  the 
surface,  the  problem  appears  ridiculously 
difficult.  But,  a  smart  manager  will  see  the 
problem  as  similar  to  everyday  life  and 
should  try  to  create  a  similar  environment. 
Managers  must  know  their  strengths  and 
weaknesses;  what  they  can  directly  control 
and  what  they  have  to  rely  upon  others  for 
help.  They  must  also  become  a  member  of  a 
larger  standards  community.  All  managers 
should  be  strong  in  knowing  wh.it  their 
information  resource  requirements  are.  They 
can  help  the  community  by  expressing  these 
requirements  in  the  form  of  community 
standards.  For  significant  portions  of  their 
AIS  security  requirements,  services  offered 
by  national  resources  can  help  the  manager  in 
areas  of  technical  expertise. 
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INTRODUCTION 

This  paper  describes  the  process  of 
computer  security  evaluations  as  presently 
performed  by  the  National  Computer  Security 
Center  (the  Center) .  This  subject  is 
important  for  a  number  of  reasons.  The 
first  is  that,  because  the  Center  has 
organized  the  evaluation  process,  there  are 
many  others  who  may  benefit  from  sharing 
this  information.  There  are  many 
organizations  that  evaluate,  or  certify 
system  security,  or  that  are  involved  in 
planning  for  a  certification.  What  the 
Center's  evaluators  do  is  not  significantly 
different  from  what  these  groups  do,  and 
the  process  used  by  the  Center's  evaluators 
is  something  that  can  be  adapted  for  use  by 
others.  The  Center  has  organized  the 
process  so  that  it  can  be  controlled  and 
managed.  This  paper  describes  how  this  was 
accomplished,  what  the  Management  Plan 
consists  of,  and  some  of  the  details  of  the 
evaluation  process. 

A  second  reason  for  this  subject  is 
that  so  many  vendors  and  developers  have 
asked  questions  such  as,  "What  do  you  do  in 
an  evaluation?"  and  "What  does  an 
evaluation  of  a  computer  product  consist 
of?"  I  hope  to  answer  those  kinds  of 
questions  and  hope  to  provide  an 
understanding  of  what  happens  during  an 
evaluation. 

INITIAL  PROCESS 

In  the  beginning,  computer  security  was 
something  of  a  void.  The  Center's  purpose 
was  to  provide  a  list  of  evaluated  products 
that  the  Federal  agencies  could  purchase 
off-the-shelf,  with  the  knowledge  that  thi 
product  met  a  certain  standard  of  security. 


The  Center  was  formed  in  mid-1901,  and 
the  first  secure  product  evaluations  began 
late  in  1982.  Evaluations  really  picked  up 
in  the  following  year  when  the  Criteria  was 
published.  At  that  time,  the  evaluation 
staff  consisted  of  only  five  evaluators 
from  the  Center,  augmented  by  additional 
evaluators  from  the  MITRE  Corporation  and 
the  Aerospace  Corporation. 

At  that  time,  the  evaluation  process 
didn't  really  exist,  because  nobody  had 
ever  tried  to  do  an  evaluation  like  this 
before.  It  was  a  totally  new  procedure. 

The  evaluators  didn't  even  have  a  final 
version  of  the  Criteria  at  the  start.  I.i 
addition,  a  strong  concern  for  quality 
hampered  the  development  of  evaluation 
procedures.  Center  management  closely 
reviewed  the  evaluation  work  and  draft 
evaluation  reports  to  ensure  the  level  of 
quality  in  an  evaluation  because  they  felt 
that  acceptance  of  the  Center  by  the 


computer  industry  depended  heavily  on  the 
first  evaluation  efforts. 


THE  MANAGEMENT  PLAN 

During  the  first  evaluations,  it 
appeared  that  the  evaluators  weren:t  doing 
evaluations  very  efficiently,  and  that  it. 
took  too  long  to  complete  an  evaluation. 
Because  no  planning  and  management  tools 
were  in  place,  it  was  not  possible  to 
measure  efficiency,  effective  use  of 
resources,  or  adherence  to  schedules. 

In  order  to  improve  the  evaluation 
effort,  the  Center's  Evaluation  Division 
has  sponsored  seven  semi-annual  Evaluators' 
Workshops  since  September  1963.  The 
Workshops  are  held  to  discuss 
interpretations  of  the  Criteria,  to  share 
experiences  in  evaluations,  and  to  resolve 
evaluation  issues  faced  by  the  evaluators. 


In  October  1981,  following  one  of 
these  workshops,  the  Aerospace  corporation 
was  commissioned  to  develop  a  Management 
Plan  for  the  evaluation  effort.  This 
document  was  developed  through  an  analysis 
of  past  evaluations.  Every  evaluator 
associated  with  the  Center  participated  in 
developing  the  plan,  and  the  plan  was 
issued  in  October  16  8  5..  It  included  all 
the  things  that  had  been  done  correctly, 
omitted  the  things  done  incorrectly,  and 
was  general  enough  to  leave  room  for  all 
the  things  the  evaluators  have  learned 
since  then.  The  Management  Plan  turned  out 
to  be  a  real  success.  It  made  an 
evaluation  a  much  more  orderly  process. 

One  purpose  in  developing  the 
Management  Plan  was  to  help  the  evaluators 
PLAN  evaluations,  something  that  had  not 
been  done  very  well  at  all,.  This  was  to  be 
expected.  The  evaluators  were  skilled  ir. 
areas  such  as  security,  computer 
technology,  and  operating  systems.  Host  of 
them  had  very  little  exposure  to  formal 
planning  and  didn't  really  want  to  know  any 
more  about  it  either.  The  Management  plan 
solved  this  problem.  It  detailed  ell  the 
tasks  that  are  a  part  of  an  evaluation.  It 
also  provided  a  list  of  tools  and  reference 
material  available  for  each  task,  end 
enumerated  factors  which  should  be  taken 
into  consideration  when  calculating  the 
duration  of  each  task.  The  Management  Plan 
is  not  merely  a  checklist,  it  is  a 
resource  used  by  the  evaluators  to  help 
them  decide  which  tasks  are  appropriate, 
how  they  relate  to  each  other,  in  what 
order,  and  how  long  they  can  be  expected  to 
take. 

Another  purpose  of  the  Management  Plan 
is  to  provide  a  measure  of  control  to  the 


process.  The  earlier  evaluations  were 
driven  by  the  system  developer's  schedule, 
which  obviously  includes  many 
considerations  other  than  security.  The 
developer  is  in  business  to  m<V  '•  a  profit, 
and  must  use  his  resources  eff  liently  in 
order  to  do  so.  Without  a  plan,  the 
evaluation  process  was  geared  to  the 
vendor's  schedule.,  and  the  Center  had  no 
control  over  the  schedule.  Because  the 
Center  is  spending  taxpayers'  money,  it 
must  also  use  its  resources  efficiently. 

By  presenting  the  system  developer  with  a 
plan  for  an  evaluation,  and  by  showing  that 
it  is  a  reasonable  , lan,  it  is  possible  to 
prepare  a  mutually  agreeable  schedule  and 
adhere  to  it.  As  &  result,  everybody 
involved  in  the  evaluation  process  - 
including  Center  management,  the  vendor, 
and  the  evaluator  -  is  happier. 

When  things  somehow  fail  to  go 
according  to  the  plan,  as  they  seem  to  do 
in  any  endeavor,  tools  provided  under  the 
Management  Plan  alert  Center  management  to 
assist  the.  team  and  the  vendor  to  get 
things  back  on  track.  The  Center  managers 
need  and  use  inputs  from  both  the  team  and 
the  vendor.  Just  as  the  team  may  have, 
problems  with  the  vendor's  ability  to  meet 
their  needs,  the  vendor  nay  disagree  with 
the  team's  interpretation  of  the  Criteria, 
the  speed  at  which  it  appears  to  be 
working,  or  perhaps  its  ability  to 
understand  the  vendor's  point  of  view.  The 
Management  rinn  has  bui It-in  feedback  loops 
through  successively  higher  management 
levels  to  resolve  team/vendor  issues  and 
bring  the  evaluation  to  a  successful  end. 

EVALUATION  PHASES 

In  organizing  the  evaluation  effort, 
the  Center  first  divided  the  evaluation 
effort  into  two  distinct  parte.  The  two 
parts  have  been  known  as  the  Developmental 
Phase  and  the  Formal  Phase  of  an 
evaluation.  The  first  part  is  currently 
called  a  design  analysis,  and  the  second  is 
called  an  implementation  analysis. 

The  two  phases  of  an  evaluation  are 
substantially  different.  The  Center  wants 
to  be  involved  with  a  developer  at  the 
beginning  of  the  design  stages  of  a  new 
system,  when  there  is  the  greatest 
opportunity  to  influence  the  design,  or  at 
least  the  security  aspects  of  the  design. 
It's  to  the  advantage  of  the  vendor,  too, 
because  correcting  design  flaws  is 
increasingly  more  expensive  as  one  proceeds 
with  the  design  process.  The  problem  at 
this  stage  is  that  there  is  usually  little 
or  nothing  to  evaluate,  it's  difficult,  to 
do  a  rigorous,  technical  evaluation  of 
something  that  doesn't,  yet  exist.  The 
second  part  of  an  evaluation,  the 
implementation  analysis  phase,  is  something 
that  should  !>«  completed  as  expeditiously 
as  possible.  This  is  to  the  advantage  cf 
both  the  Center  and  the  vendor.  When  the 
vendor  HAS  a  final  product,  and  is  fully 
prepared  to  provide  ALL  the  evidence 
necessary  to  a  low  that  it  is  a  secure 
product,  then  Che  evaluators  want  to 
examine  that  evidence  to  the  best  of  their 


ability  and  bestow  a  rating  as  quickly  as 
possible. 


DESIGN  ANALYSIS  PHASE 

The  design  analysis  phase  of  an 
evaluation  is  a  consulting  relationship. 

The  members  of  a  desiyn  analysis  team  are 
the.  most  experienced  evaluators.  They  are 
able  to  assess  the  consistency  of  the 
design  against  the  requirements  of  the 
Criteria.  The  design  gives  the  teas'  a  solid 
assurance  as  to  how  well  the  requirements 
will  be  satisfied.  The  team  members  can 
answer  the  questions  such  as  "Is  this  good 
enough?"  or  "On  a  scale  of  1  to  10,  where 
do  I  stand?" 

The  central  task  in  a  design  analysis 
is  called  Systems  Analysis  and  Technical 
Support,  and  is  performed  through  technical 
interchange  meetings  with  the  vendor.  The 
level  and  nature  of  support  vary  widely. 
Critical  factors  in  determining  the  level 
of  support  tve  the  vendor's  experience, 
candidate  level  of  the  Criteria,  and 
whether  the  product  it  an  existing  product 
or  a  totally  new  design. 

The  Management  hi an  provides  very 
detailed  guidance  to  both  the  evaluator  and 
to  management,  while  still  allowing  for 
judgement  by  the  team  leader,  k  small 
sample  of  tasks  that  make  up  the  design 
analysis  phase  of  an  evaluation  are  the 
following: 

c  Develop  Verification  Plan  ( B?  +) 
o  Develop  Training  Plan  (for  formal 
team; 

o  Determine  Configuration  Range 
o  Analyse  Documentation  idraft  ok) 
as  it  in  developed 
o  Educate  the  vendor's  technical 
staf  f 

o  Determine  when  ready  to  prepare 
the  Initial  Product  Assessment 
Report  (IPAR) 

o  Determine  candidate  Evaluation 
Class 

Each  task  in  the  Management  Plan  is 
subdivided  into  a  set  of  subtavks  whenever 
possible.  For  example,  the  task  labelled 

a  naive  is  of  suet.  em  documentation  i  s 
subdivided  by  the  individual  requirements 
t or  documental-  i  or: : 

o  Formal  Top  Level  Specifications 
( FTLS ) 

o  Descriptive  Top  I*vel 

Specifications  (DTLS) 
o  Formal  Security  Policy  Model 

;e.g.  Bell/LaP-adula} 
o  Security  Features  User's  Guido 

(SFUG) 

o  Trusted  Facility  Manual  (TSM) 

o  Covert  Channel  Analysis 

o  Test  Plan 

In  order  to  document  the  first  phase 
of  the  evaluation,  the-  evaluation  team 
writes  an  Initial  Product  Assessment  Report 
(IPAR) .  This  document  assures  that  all 
Criteria  requirements  have  been  addressed. 


end  that  the  IPAR  contains  sufficient 
product  information  to  form  a  basis  for  the 
decision  regarding  whether  to  proceed  to  a 
Formal  Evaluation,  or  Implementation 
Analysis.  It  documents  the  justification 
for  the  candidate  rating,  the  team's 
understanding  of  the  product,  and  the 
vendor's  understanding  of  the  Criteria. 

This  completes  the  first  phase  of  an 
evaluation  -  the  design  analysis  phase. 
Portions  of  the  evaluation  dealing  with 
administration  and  management  review  of  the 
process  have  been  omitted  in  order  to  focus 
on  the  technical  areas,  but  they  are 
definitely  a  part  of  the  Management  Plan. 


IMPLEMENTATION  ANALYSIS 

The  second  phase  of  an  evaluation  is 
called  the  implementation  analysis  phase. 

It  was  formerly  known  as  the  formal 
evaluation,  and  it  is  what  most  people 
think,  of  when  they  think  of  an  evaluation. 

The  description  that  appears  below  is 
common  to  all  the  evaluation  work  performed 
by  the  Center  and  applies  equally  to 
sub-systems  evaluations,  operating  system 
evaluations,  network  evaluations,  and 
evaluations  of  database  management  systems. 
The  guiding  principle  is  that  the  vendor 
provides  ail  the  evidence  needed  to  judge 
the  quality  of  security  in  a  given  product, 
and  the  evaluation  team  analyzes  that 
evidence. 

The  distinct  elements  of  the 
implementation  analysis  are: 

o  Planning 
o  Education 
o  Analysis 
o  Draft  Final  Report 
o  Test  Plan 
o  Testing 

o  Configuration  Management  Review 
o  Final  Report  and  Fating 

Planning:  The  very  first  thing  that 
happens  in  an  evaluation  is  the  development 
of  a  work  plan  for  the  evaluation.  This 
plan  is  developed  by  the  evaluation  team, 
agreed  to  by  the  vendor,  and  approved  by 
Center  management.  Adherence  to  the  plan 
is  enforced  through  regularly  scheduled 
reviews  by  Center  management.  This  is  done 
through  informal  reviews  and  briefings, 
meeting  reports,  trip  reports,  and  monthly 
status  reports  submitted  by  both  the  team 
and  the  vendor. 

Education:  It’s  important  that  the 

evaluation  team  fully  understand  the 
functionality  and  interfaces  of  the  product 
to  be  examined.  Although  the  original  team 
helped  the  vendor  define  and  scnedule  the 
training  plan,  the  training  doesn't  occur 
until  the  secone’  phase  of  the  evaluation. 
Education  is  important  in  this  phase 
because  the  analysis  occurs  on  a  much 
greater  level  of  detail. 

Analysis:  The  team  analyzes  the 
documentation  that  was  reviewed  during  the 
first  phase  of  the  evaluation,  but  at  a 


much  greater  depth.  The  documentation 
analysis  is  followed  by  an  analysis  of 
source  code  because,  after  all,  this  IS  an 
implementation  analysis.  The  team  must  be 
certain  that  the  design  has  been 
implemented,  and  implemented  correctly. 

They  need  assurance  that  the  system 
actually  works  as  advertised.  The 
Management  Plan  is  still  incomplete  in  this 
area,  and  there  is  an  or-going  effort  to 
define  this  process  more  rigorously  and  in 
greater  detail.  In  general,  individual 
team  members  pursue  areas  of  documentation 
and  code  that  correspond  co  the  various 
sections  of  the  Criteria.  The  approach 
varies,  depending  on  the  target  rating.  At 
the  lower  levels  of  the  criteria, 
evaluators  are  primarily  concerned  with 
functional  mechanisms,  such  as 
discretionary  access  controls,  auditing, 
and  identification  and  authentication.  At 
the  higher  levels,  the  assurances  provided 
through  system  architecture,  configuration 
management,  and  formal  verification  are 
more  important. 

Draft.  Final  Report:  Throughout  the 
previous  steps,  beginning  in  the  education 
phase,  team  members  take  notes  and  mentally 
organize  the  sections  of  the  final  report 
for  which  they  are  responsible.  As  their 
understanding  of  the  system  grows,  the 
first  draft  of  the  final  report  is  written. 

Test  Plan:  The  test  plan  is  the  work  plan 
for  the  system  testing  phase  of  the 
evaluation.  It  describes  the  functional 
tests  to  be  conducted  and  specifies  test 
procedures.  As  in  all  the  sections  of  the 
Management  Plan,  this  section  incorporates 
the  flexibility  to  deal  with  evaluations  at 
any  candidate  class  of  the  Criteria.  For 
example,  for  B2  level  systems  and  above, 
the  test  plan  includes  the  penetration 
testing  methodology  and  any  testing  related 
to  the  vendor's  covert  channel  analysis. 

The  plan  provides  a  schedule  for  testing, 
identifies  the  test  site,  and  describes  the 
system  configuration  to  be  tested. 

Testing:  In  order  to  support  the  assurance 

obtained  through  analysis  of  documentation 
and  code,  a  certain  amount  of  testing  must 
be  done.  The  objective  is  to  execute 
security-related  functional  tests  for  tha 
candidate  system.  The  team  examines  the 
vendor's  functional  tests  and  evaluates  the 
results.  Where  necessary,  the  team 
develops  additional  tests  to  ensure  that 
all  of  the  features  are  adequately  tested. 
When  errors  ate  found,  the  vendor  is 
expected  to  correct  them.  The  team 
documents  its  findings  in  the  final  report. 

Configuration  Management  Review :  The 
Center's  purpose  in  configuration 
management  is  to  ensure  that  changes  to  the 
system  can  be  traced  from  beginning  to  end, 
and  vice  versa.  The  evaluators  should  be 
able  to  trace  a  trouble  report  all  the  way 
down  to  the  exact  location  of  code  changes. 
They  should  also  be  able  to  trace  code 
changes  back  to  the  reasons  for  the 
changes.  If  it  is  known  what  changes  have 
taken  place,  their  effect  on  the  security 
of  a  system  can  be  assessed.  Although  the 
Criteria  doesn’t  require  configuration 
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management  until  the  B2  level,  the  Center 
now  looks  for  it  on  all  systems  as  a 
practical  matter.  The  Center  is  very 
reluctant  to  consider  maintenance  of  an 
initial  rating  over  subsequent  releases  of 
a  product  unless  an  approved  configuration 
management  system  has  been  implemented. 

Final  Report  and  Rating:  When  the  testing 
has  been  completed,  the  team  knows  the 
product  as  well  as  it  is  ever  going  to,  and 
is  ready  to  complete  the  evaluation.  The 
draft  final  report  is  modified  based  on  the 
recommendations  of  the  Technical  Review 
Board  (TRB)  and  the  additional  information 
learned  during  system  testing.  The 
evaluation  is  complete  when  the  Center's 
rating  is  awarded,  the  product  is  entered 
on  the  Evaluated  Products  List,  and  the 
Final  Report  is  published. 

Throughout  the  course  of  an  evaluation 
the  team  has  ready  access  to  technical 
specialists  within  the  Center.  These 
people  are  the  Chief  Evaluator,  Senior 
Scientist,  and  Chief  Scientist.  Those 
people  are  involved  daily  with  the 
twenty-five  evaluations  currently  in 
progress.  In  addition  to  providing 
technical  expertise,  they  are  also  able  to 
help  the  team  separate  technical  issues 
from  administrative  and  management  issues. 
All  this  helps  to  keep  an  evaluation  on 
course. 

The  quality  control  function  mandated 
by  the  Management  Plan  is  the  Technical 
Review  Board,  or  TRB.  The  primary  purpose 
of  this  board  is  to  verify  the  team's  depth 
of  understanding  of  the  product  under 
evaluation  and  to  assure  consistency  with 
other  evaluations.  The  TRB  may  approve  the 
team's  progress,  or  it  may  recommend  that 


the  team  investigate  some  areas  more 
thoroughly  before  proceeding  to  the  next 
phase . 

The  TRB  reviews  the  work  of  the 
evaluation  team  at  least  three  times  during 
an  evaluation.  One  review  takes  place  at 
the  end  of  the  first  phase  of  an 
evaluation,  when  the  team  presents  its 
Initial  Product  Assessment  Report.  The 
second  is  a  review  of  a  draft  of  the  final 
report  and  the  team's  test  plan.  The  third 
review  is  at  the  end  of  an  evaluation,  when 
the  final  report  is  reviewed.  At  each  of 
these  reviews,  the  team  provides  the  TRB 
with  a  document  that  represents  a  great 
deal  of  work.  The  TRB  members  review  the 
information  provided,  provide  comments, 
and  ask  questions  about  the  conclusions  the 
team  has  formed.  The  team  responds  to 
these  comments  and  questions  in  a  formal 
presentation.  The  TRB  judges  the 
presentation  of  the  team  in  the  light  of 
previous  evaluations,  and  makes 
recommendations  to  the  Chief  of  the  Product 
Evaluations  and  Technical  Guidelines 
Office,  who  makes  final  decisions 
regarding  the  future  of  an  evaluation  and 
the  course  to  be  take-1  by  the  evaluation 
team. 

Conclusion 

Through  its  development  and 
implementation  of  the  Management  Plan,  the 
Center  has  rt Annnst r at Art  that  evaluation 
activities  can  be  planned,  scheduled,  and 
managed.  The  Center's  activities  closely 
mirror  normal  contractual  and  especially 
certification/accreditation  activities . 

With  minor  changes  to  particularize  this 
plan  to  other  organizations,  it  can  serve  a 
wide  variety  of  similar  functions. 
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AliSTRAt:  1 

We  have  developed  a  prototype  expert  system, 
named  XSAIT.,  for  computer  security  inspection  of  a 
VAX/VMS  system  in  a  network  env  i  ronmeiit  .  XSAPf 
attempts  to  explore  the  vulnerabilities  of  a  given 
VAX/VMS  system  using  a  remote  diagnosis  mechanism. 

The  inspection  result:,  provide  valuable  information  to 
system  management  about  further  security  improvements. 

The  computer  security  inspection  is  performed  by 
four  security  inspectors:  the  Password  Inspector,  the 
Dl. diet  Default  Account  Inspector,  the  System  Pile 
Protect  ion  Inspector  and  the  User  Applicat  ion 
Inspector. 

User  application  security  is  the  focus  of  the 
development  of  XSAIT,  since  it  is  the  weakest 
component  of  a  VAX/VMS  system  from  a  Security  point  of 
view. 

XSAPP.  has  been  field-tested  on  Digital's  interna; 
network  and  lias  produced  some  very  encouraging 
results.  The  field  test  results  have  clearly  shown 
the  potential  of  XSAI-T  as  a  centralized  security 
auditing  system  in  a  distributed  network  environment. 

1  INTRODUCTION 

XSAi-T*  is  a  prototype  cXpelt  system  that  can 
assist  a  system  manager  or  network  manager  in  the 
inspection  of  the  security  of  a  VAX/VMS**  system  in  a 
network  environment  (Tong  1986a),  XSAI-T  inspects  the 
soundness  of  the  protection  mechanism  of  a  given  system 
by  launching  an  intrusion  against  the  system. 

Computer  security  is  defined  as  the  protection 
from  misuse  of  a  computer  system,  its  applications  and 
its  shared  resources  (Neumann  1987).  This  includes 
the  notions  of  preventing  unauthorized  acquisition  and 
modification  of  information,  thus  assuring 
confidentiality  and  integrity. 

Two  approaches  to  attaining  better  security  have 
beer,  developed  over  the  past  decade.  One  is  remedial 
and  the  other  is  preventative  (Neumann  1978).  the 
first  approach  involves  evaluating  the  security  flaws 
uncovered.  The  second  approach  involves  designing  new 
systems  that  arc  secure  and  whose  security  can  in  some 
way  be  convincingly  verified. 

In  the  last  decade  a  few  preventative  models  have 
been  proposed  to  build  "secure"  computer  systems. 

These  models  include  the  lattice  model,  the  access 
matrix  model,  the  Hell  and  l.aPadula  model,  anJ  i In¬ 
security  kernal  mechanism  (I.andwehr  1981). 

The  proven! at ivc  approach  is  very  attractive  when 
a  computer  application  environment  requires  a  very- 
high  level  of  security  since  the  approach  designs 
security  into  the  computer  system.  However,  this 
approach  includes  the  follow. ng  disadvantages 
(Denning  1988) : 

-  It  is  very  expensive  to  develop,  purchase  or 
maintain  a  highly  secure  opcratii.g  system 

‘This  research  was  supported  by  Digital  f.quipnient 
Corporation's  Graduate  engineering  education  Program. 
**The  following  are  trademarks  of  the  Digital  equipment 
Corpoiation:  VAX,  VMS,  VAX/VMS  and  Dl.Cnot  . 


-  A  mode-1  for  a  secure  operating  system  in  a 
network  environment  is  not  yet  well  defined. 

-  Developing  systems  that  are  absolutely  secure  is 
extremely  difficult,  if  not  impossible. 

Thus  the  remedial  approach  is  very-  desirable  and 
and  affordable  for  computer  systems  and  applications 
that  require  a  relatively  high  level  of  security  but  at 
a  lower  cost. 

XSAI-T.  applies  this  remedial  approach  and  inspects 
the  security  aspect  of  VAX/VMS  system  in  a  network 
envi ronment . 

VAX/VMS  security  has  been  greatly  nbanced  since 
the  release  of  version  V4.0  (Digital  1984).  XSAIT 
assures  that  a  given  system  is  maintained  at  a 
relatively  high  level  of  security,  furthermore, 

VAX/VMS  is  only  os  secure  ns  the  user-written 
application  programs  that  arc  layered  on  top  of  VMS. 
Therefore,  there  is  a  need  to  develop  a  method  to 
detect  violations  of  a  site-dependent  security  policy 
for  a  given  system.  The  method  developed  by  XSAIT  is 
to  apply  export  system  technology  to  the  domain  of 
computer  security. 

An  expert  system  approach  to  the  security 
inspection  of  a  given  VAX/VMS  system  is  strongly 
motivated  by  the  following  factors: 

-  Security  exports  arc  rare. 

-  A  very  special  type  of  knowledge  is  required  to 
discover  the  vulnerabilities  of  a  computer 
system.  An  expert  system,  by  nature,  is  capable 
of  capturing  and  applying  the  expertise  in  a 
very  narrow  domain. 

-  The  analysis  of  system  security  requires  much 
knowledge  of,  and  experience  with,  the  VAX/VMS 
operating  system.  It  is  possible  to  express 
this  knowledge  and  use  it  in  on  expert  system. 

-  The  task  of  adequately  exploring  the 
vulnerabilities  of  a  VAX/VMS  system  would  become 
intractable  without  heuristic  methods  for 
probing  a  computer  system. 

-  An  expert  system  has  the  potential  to  provide 
some  explanation  of  how  the  security  violations 
were  discovered. 

-  An  expert  system  is  capable  of  interacting 
actively  with  a  user  to  gather  site-dependent 
VAX/VMS  paramet ers . 

In  the  computer  security  domain  there  exist  very- 
few  expett  systems.  The  proposed  1D|;S  model  by  SRI  is 
implemented  as  a  real-time  Intrusion-Detection  I.xpert 
System  (Denning  198S).  However,  IPIS  differs  from 
XSAI'I  as  follows: 

-  IDIS's  approach  is  t.  detect  an  intrusion 
whereas  XSAIT-:' s  approach  is  to  launch  the 
intrusion  thus  testing  the  soundness  of  the 
protection  mechanism  of  a  given  system. 
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-  To  improve  performance  IPIS  requires  a  separate 
processor,  perhaps  a  personal  computer,  to 


process  system  audits  as  they  arc  recorded. 
XSAIT:  runs  only  when  needed  and  remotely  in  a 
distributed  network  environment. 


Figure  1:  The  Architecture  of  XSAEE. 


-  It  allows  security  inspectors  to  perform  their 
security  inspection  independently. 

-  It  allows  higher-level  security  inspectors  to 
draw  conclusions  from  conclusions  and  evident* 
provided  by  lower-level  security  inspectors. 

The  XSAIT-:  Analyst  provides  an  integrated  security 
View  of  the  system  under  inspection.  The  Security 
Inspectors  work  independently  of  each  other.  The  XSAI-E 
Analyst  examines  those  situations  which  the  security 
inspectors  arc  not  able  to  examine  due  to  possible 
interactions  among  inspectors.  The  XSAFI  Analyst  is 
activated  when  all  security  inspectors  have  completed 
their  inspections.  This  makes  the  XSAEE  Analyst 
capable  of  drawing  conclusions  from  evidence  and 
conclusions  already  obtained  by  t lie  security  inspectors. 

XSAIT-;  has  the  following  security  inspectors  to 
examine  various  components  of  a  VAX/VMS  system. 

-  USI.lt  APPLICATION  INSPECTOR.  Checks  if  a 
user-written  application  installed  on  a  VAX/VMS 
system  has  imposed  a  security  threat  to  the 
underlying  system. 

-  PASSWORD  INSPECTOR.  (.hecks  if  commonly  known 

passwords  can  he  used  to  log  into  1 

security-critical  accounts  on  a  VAX/VMS  system. 


IDIiS  uses  statistical  knowledge  whereas  XSAl-E. 

uses  heuristics. 

2  architecture  oi-  xsape 


-  SYSTEM  l-Il.i;  PROTECTION  INSPECTOR.  Checks  if 
security-critical  system  files  tire  properly 
protected. 


The  architecture  of  XSAP1.  is  a  hierarchy  of  active 
inspection  agents.  XSAiT  consists  of  a  set  of  Security 
Inspectors,  that  contain  the  security-specific 
knowledge  in  the  system,  and  a  common  working  memory 
which  serves  as  the  blackboard  to  which  all  the 
security  inspectors  have  access,  figure  1  shows  the 
architecture  of  XSAEE. 

The  lines  with  arrows  in  the  figure  indicate 
read/write  access  to  the  working  memory.  The  lines 
without  arrows  in  the  figure  indicate  control 
relationships  among  the  security  inspectors.  Inch 
Security  Inspector  consists  of  a  set  of  security 
subinspectors  with  a  local  working  memory  shared  among 
the  suh  inspect  or  s  .  Some  subinspectors  arc  further 
subdivided  into  specialists. 

The  architecture  of  XSAIT:  establishes  a  multi-level 
inspection  structure:  the  XSAIT  Analyst  level,  the 
Inspector  level,  the  Suhi aspect  or  level  and  the 
Specialist  level.  This  inspection  structure  resembles 
the  Blackboard  architecture  somewhat.  However,  the 
difference  between  the  two  architectures  is  that  there 
is  no  direct  control  of  the  activation  of  each  KS  in 
the  Blackboard  architecture,  whereas  in  the  XSAIT 
architecture  security  inspectors  are  activated  in  a 
predefined  sequence  by  the  XSAIT  Controller. 

XSAU  uses  ibis  type  of  architecture  for  the 
following  reasons: 

-  It  provides  a  uniform  structure  of  the  common 
working  memory.  This  makes  it  possible  to 
integrate  new  security  inspectors  into  the 
system  easily  and  to  develop  a  set  of  utilities 
applicable  to  all  security  inspectors. 

-  It  provides  a  shared  database  where  evidence  of 
suspected  weaknesses  ami  identified  security 
weaknesses  of  a  VAX/VMS  system  arc  recorded, 

-  It  allows  security  inspectors  to  use  different 
knowledge  representations  and  different 
problem-solving  methods,  hut  allows 
communication  via  the  common  working  memory. 


-  DECNET  DEFAULT  ACCOUNT  INSPECTOR.  Checks  if  the 
DliCnct  default  account  is  set  lip  securely, 

XSAI  f  has  been  implemented  in  Knowledge  Craft*** 
(Carnegie  198S),  mainly  because  security  inspection  of 
a  VAX/VMS  system  cannot  be  accomplished  by  any  one 
problem  solving  approach.  Knowledge  Craft  allows 
flex ib]«  knowledge  representations,  and  alternative 
prohlep.-solving  and  control  strategies, 

,t  nir  security  inspectors 

3,1  The  User  Application  Inspector 

There  has  been  little  research  and  development 
done  in  the  area  of'  user-writ  t  cn  application  security 
in  the  past  doade.  Most  research  in  computer 
security  has  been  conducted  in  areas  such  ay  forma] 
models  for  computer  security,  verification  of  security 
and  computer  network  security.  The  complexity  ol  user 
application  security  has  also  made  it  difficult  to 
perform  research  in  this  area. 

As  research  in  formal  models  an-J  verification  of 
computer  security  has  gradually  become  reality, 
operating  systems  are  designed  and  implemented  more 
sccii.cly.  Therefore,  there  is  a  need  to  develop  a 
methodology  to  ensure  that  user  applications  do  not 
compromise  the  underlying  secure  operating  system. 

The  exploration  of  AI  techniques  such  as  expert 
systems  in  the  computer  security  domain  provides  a 
possible  solution  to  the  problem  of  user  application 
security.  This  is  because  cxp«  rt  systems  are  capable 
of  capturing  human  heuristics  which  are  used  in  t  In¬ 
security  inspect  ion  of  a  user  application. 

An  example  of  a  user  application  could  be  ail  auto 
parts  inventory  ordering  system  where  customers  can  log 
into  the  system  remotely  and  make  orders  of  auto  parts 
through  the  application  software.  Another  example  of  a 
user  application  could  he  a  slock  purchasing  system 
where  investors  can  look  up  information  and  prices  of 
various  stocks  and  make  orders  to  buy  or  sell  stocks. 

•••Knowledge  draft  is  a  trademark  of  Carnegie  Croup  Inc. 
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11  the  stock  purchasing  system  mentioned  above  was  not 
set  up  securely,  a  stock  holder  might  gain  access  to 
the  master  database  and  change  it  to  his  advantage. 

The  "User  Contiol  Hypothesis"  (Anderson  1972)  says 
that  security  vulnerability  is  a  function  of 
user-controlled  shared  resources.  In  other  words  the 
less  resource  a  user  has  access  to,  the  fewer  security 
weaknesses  he  will  be  able  to  discover.  Hence,  the 
major  task  of  the  User  Application  Inspector  is  to 
reveal  those  security  weaknesses  which  are  caused  by 
inadequate  control  over  the  use  of  resources. 

Another  task  of  the  User  Application  Inspector  is 
to  reveal  system  integrity  flaws  cxplorahlc  in  a 
user-written  application.  A  user  application  is  a 
piece  of  software  developed  to  meet  some  needs  of  a 
group  or  groups  of  people. 

There  are  four  subtasks  in  the  security  inspection 
of  a  user-written  application.  The  subtasks  are 
carried  out  by  the  f o  . lowing  four  sub inspectors  and 
their  specialists: 

-  The  Network  Communication  Sub  inspector 

-  The  Captive  Account  Suh inspect  or 


appropriate  here,  since  the  inspection  is  done  by 
recognizing  a  situation  whore  there  is  a  security 
viol at  ion . 

3.1.2  The  Captive  Account  Suhi nspector  The  major  task 
of  the  ('apt  ive  Account  Sub  inspector  is  to  inspect  an 
application's  record  in  the  User  Authorization  file 
(MAP)  ami  to  ensure  that  the  setup  of  the  account 
complies  with  the  requirements  for  the  application. 

Any  violation  of  the  requirements  constitutes  a 
security  weakness.  If  an  application  requires  that  a 
user  can  net  get  to  the  supervisor  level,  the  Captive 
Account  Subinspector  checks  for  certain  qualifier:;  in 
the  account's  UA!;  record  to  ensure  this  requirement 

Most  often  a  perpetrator  finds  his  first 
opportunity  to  break  out  of  the  control  of  a  user 
application  by  locating  insecure  setup  of  a  user 
account . 

There  are  two  types  of  login  restrictions  that  can 
be  assigned  to  an  account  via  the  AUTHOR  I  ?.i:****Ut  i  1  ity 
in  VAX/ VMS: 

-  1 .00 IN  M01 1 1  RI-STICTIONS.  Limit  logins  to 
specific  types  of  login 


-  The  Login  Procedure  Sub  inspect  or 

-  The  Application  Program  Subinspect or  which  has 
an  Executable  image  Specialist  and  a  Program 
Code  Specialist 

The  structure  of  the  User  Application  Inspector  is 
shown  in  figure  2.  The  lines  with  arrows  in  the  figure 
indicate  working  memory  accesses.  The  lines  without 
I  arrows  in  tiie  figure  indicate  ul  at  icm-O.  ips  among  the 

I  inspector,  suh inspectors  and  specialists. 
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1  igui'c  2:  The  Structure  of  the  User  Application 
1 nspec t  or 

3^1  . 1 _ Thi-  Network  ('onimunicat  ion  Suh  inspect  or  The  major 

task  of  the  Network  Communication  Subinspvctor  is  tu 
check  for  possible  security  problems  with  an 
application  that  car.  be  used  over  a  network.  An 
example  could  be  an  application  accessing  a  database  on 
another  node. 

1  l-.e  following  aspects  are  inspected: 


-  LUNCTION  RESTRICT IONS.  Limit  types  of 
activities  of  the  user  account 

The  Captive  Account  Subinspect or  gathers 
information  about  an  account  set-up,  and  about  the 
requirements  of  the  application  via  sessions  of 
questions.  Next  the  Captive  Account  Sub  inspect  or 
inspects  the  account  by  running  rules  against  the 
gathered  information.  These  rules  detect  situations 
where  the  Login  mode  and  function  restrictions  arc 
insufficient  to  comply  with  the  requirements  of  t he 
appl ieat ions . 

3.1.3  The  Login  Procedure  Sub  inspect  or  The  major  task 
of  the  login  Procedure  Subinspector  is  to  discover 
paths  that  allow  escape  to  the  supervisor  level  ("J" 
level  in  VMS)  and  those  that  break  the  control  of  a 
login  procedure.  The  login  procedures  include  both  the 
user  login  command  procedure  and  the  system  login 
command  procedure. 

There  arc  various  aspects  of  a  login  pjoccdure 
that  a  perpetrator  may  examine  to  escape  to  the 
supervisor  level.  Some  of  the  potential  paths  involve 
error  and  program  abortion  handling  within  The  command 
procedure  and  the  use  of  the  IH’l  command  1NQU1UI  which 
takes  input  from  a  user. 

A  procedural  knowledge  representation  is 
appropriate  for  the  Login  Procedure  Sub  inspect  or,  since 
the  inspection  is  accomplished  by  parsing  the  command 
procedures  and  searching  for  the  ptesence  ot  certain 
bt'l  commands. 

3.1  .4  1  lie  Application  Program  Subinspect  t»r  A  user 

application  may  compromise  security  because  there  are 
errors  or  flaws  in  the  design,  implementation, 
ope rat  ion  and  maintenance  of  the  application.  Some 
applications  may  have  the  image  of  the  application 
installed  with  privileges  for  various  reasons,  oi  the 
application  may  be  running  under  a  piivilcgid  account. 
These  privileged  applications  could  substantially 
damage  a  VAX /VMS  system  when  misused  by  a  perpetrator, 

Ibt-  major  task  of  t be  Application  Program 
Sub  inspect  or  is  to  detect  abuse  of  user  functions 
provided  bv  the  application.  lor  instance,  a  user 
could  modify  the  User  Authorization  1  i 1 e  it  the 
application  provides  the  user  an  editor  fund  ion  and  is 
installed  with  SYSPKV  prhilfge.  The  Application 
Program  Sub  i  nsped  or  inspects  an  application  with  t *.» 

****'1110  AUTHOR  1 2 1  Utility  is  used  to  maintain  nsci 
accounts  defined  by  records  in  a  file  (  S\  S$S'i  ST  1  M : 
SYSU.M  .IU*I)  cal  led'  the  User  Authon:at  ion  IiL-  (U\!) 


-  I  n  form  t  ion  communicated  in  plain  text 

-  Passwords  being  transferred  over  the  network 
A  rule-based  knowledge  representation  is 
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security  specialists:  the  Executable  linage  Specialist 
and  the  Program  Code  Specialist, 

The  Executable  Image  Specialist  examines  an 
application  at  a  nunc  conceptual  level  without  concern 
about  the  actual  coding.  It  reveals  malicious  use  of 
functions  and  privileges  provided  Tired))*  to  users  and 
draws  its  conclusions  based  on  what  the  functions  can 
accomplish.  Possible  scenarios  of  abuse  have  been 
preset. ted  in  (Teng  198(>h)  , 

A  rule-based  Knowledge  ^presentation  is  used  here, 
figure  3  shows  a  rule  in  CRI.-OPS  for  the  Executable 
Image  Specialist.  The  rule,  lure  written  in  move 
natural  language,  records  a  situation  where  the 
following  security  violation  has  been  discovered: 

IF 

Installed  privileges 
=  ( B VPASS/S YSPRV/Rh ADALU  > 

AND  functions  of  the  application  =  (READ/MAIL/COPY) 

AND  file  names  are  specified  by  users  or*  modifiable 

logical  names 

THEN 

Security  violation  =  "any  file  including  SYSUAF.DAT 
can  be  accessed" 

The  Program  Code  Specialist  is  activated  only  il 
the  application  program  source  code  is  available.  It 
examines  the  coding  of  the  application  for  security 
violations.  The  Program  Code  Specialist  has  not  been 
implemented.  However,  it  is  proposed  that  the  "Flaw 
Hypothesis  Methodology"  (Attanasio  197n)  be  used  to 
deter t  security  weaknesses  in  the  coding  of  a  user 
application  piogiaiu.  The  improvement  to  that 
methodology  is  the  introduction  of  A1  techniques 
allowing  human  heuristics  to  be  captured. 

3.2  The  System  File  Protection  Inspector 

VAX/VMS  maintains  many  system  files  that 
participate  in  various  activities  that  Keep  the 
operating  system  functioning  properly.  These  system 
files  are  critical  to  the  security  of  a  VAX/ VMS  system. 
The  major  tasK  of  the  System  file  Protection  Inspector 
is  to  check  if  these  system  files  such  as  the  Pscr 
Authorization  File  and  system  startup  files  are 
properly  protected.  The  System  lilc  Protection 
Inspector  performs  a  sequence  of  probes  to  detect 
improperly  protected  system  files,  Hei-ce,  a  procedural 
knowledge  representation  is  appropriate  for  the  System 
File  Protection  Inspector.  A  remote  inspection  of 
system  files  is  accomplished  by  specifying  the  remote 
node  name  with  the  system  file  specification. 


(T  imagr_read_wiUi_inatalled.ptivilcgra 


(control  “inspector  user .appl icat ion 

“eubinapectoi  appl  icalicn_p*ogt  on> 

“nrttion  execut.ablc.lmagr) 

(account .inspected 

*UBPinnnip_f  iclJ  suaeiname*) 

(appl i cation. ins tallcd.pr ivi leges 
“uocrnaine.i  icld  <UBcrnajne> 

“installed. privileges  <<  BYPASS  SYSI'RV  REAUALL  >>) 

(application_tuni_t  \oiib 

‘username. f ield  <username> 

"functions  .provided  <<  FI  l.F._SPF.C  1 1‘ICAT  ION.UY  _USKR 

FlLE.SPFCtFICATION.ny.NUUiF I AHLE.LOG 1CAL.HAME  *>) 
(appl icat ion. 1 unci ions 

'uBcrname.f  ield  <usernairie> 

'functions. provided  <<  VAXHA1L  COPY  READ  >>  ) 

- -> 

(Add  value  xaaf r_i esults 

’results.from .executable. image. specialist 

’image .read. aith.i natal led.prii Lieges) 

)  ;  End  of  imagc.r cad. ■ lth. muta 1 led. pi i vi leges 

figure  3;  A  Rule  from  the  Ixecutablc  linage  Specialist 

3.3  The  Password  Inspector 

The  major  task  of  the  Password  Inspector  is  to 
detect  the  use  of  commonly  Known  passwords.  There  are 
two  types  of  commonly  Known  passwords:  a  distributed 
password,  which  is  a  password  that  comes  with  the 
initial  VAX/VMS  system  and  is  documented  in  the 
installation  guide;  and  a  guessable  password  which  is 
easily  obtained  by  some  simple  scheme. 

The  Password  Inspector  inspects  passwords  t o  the 
SYSTEM  account ,  the  PI  FID  account,  the  SYSTIS1  account  , 
and  any  computei  operational  account  such  as  the 
HACKDP  account,  as  will  as  accounts  required  by  the 
installation  of  software  layer  products  such  as  the 
MRMANAO! K  account  for  the  Message  Router  software. 

The  Password  Inspector  performs  a  sequence  of 
probes  to  detect  commonly  Known  passwords. 

Consequent ly,  a  procedural  Knowledge  representation, 
using  I. ISP,  is  appropriate  for  the  Password  Inspector. 

3.4  The  Pdf  net  Default  Account  Inspector 

The  Plfiiet  default  account  is  an  account  that  is 
used  for  activating  network  processes  on  a  local  node. 
The  account  :  like  any  user  account  on  the  system  and 
has  an  entry  in  the  User  Aut  hor  l  ut  ion  File. 

The  maj»«r  task  of  the  HI  fuel  Default  Account 
Inspector  is  to  check  whether  it  is  possible  to  execute 
a  prog ram  or  to  submit  a  remote  batch  job  under  the 
PICnet  default  account,  to  check  the  authorized  and 
default  privileges  oj  the  Dlfnvt  default  account,  and 
tii  check  if  the  Id  lint  default  account  is  grouped  with 
other  ST5TIM  accounts. 

The  Dll  net  Default  Account  Inspector  pert  arms  a 
sequence  of  probes  to  detect  insecure  setjps  ot  the 
PI  Out  default  account  on  a  g«\en  node.  Hence,  a 
procedural  Knowledge  rt  p  i  osen  t  a  t  iot: ,  using  the  IH'I. 
Command  language,  is  appropriate  for  the  HI  iTict  Default 
Account  Inspector. 

4  I.V  XI.UATI  (A  Of  XSAI  I 
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The  Password  Inspector,  the  Pl.fnct  Default  Account 


Inspector,  the  System  Pile  Prole  lion  Inspector,  the 
User  Application  Inspector,  the  login  Procedure 
Suh  inspect  or,  the  Network  Comimnncal  1011  Suit  inspector, 
the  Captive  Aceuunt  Siibi  nspeetur,  and  the  Application 
['rug  ,  fill  Subinspector  with  its  Ixccutablc-  linage 
Specialist  have  been  implemented.  They  have  been 
running  on  a  VAX/ 11  785  with  52  megabytes  of  primary 
memory.  The  development  ol  the  Program  Code  Specialist 
lias  i'CL-n  left  for  future  work  on  XSAIP.. 

Alien t  44  VAX/VMS  systems  on  Digital's  internal 
network  were  inspected  by  XSAI-h.  About  half  a  dozen 
VAX/VMS  system  managers  and  VAX/VMS  application 
developers  within  Digital  Iquipment  Corporation 
participated  in  the  field  test  process.  The  overall 
result  was  impressive.  Some  problems  with  XSAPP  were 
also  discovered. 

Inch  system  was  tested  by  running  the  System  Pile 
Protection  Inspector,  the  DP.Cne-t  Default  Account 
Inspector,  and  the  Password  Inspector.  The  User 
Application  Inspector  was  run  when  there  was  suitable 
application  on  the  system  and  if  the  developers  or  the 
maintainors  of  the  application  permitted  the  inspection. 

There  were  155  security  violations  discovered  by 
X5A1 :  among  the  44  systems.  These  violations  included 
having  the  User  Authorization  Tile-  and  the  Network 
Authorization  Pile  readable  or  inod'fiable  by  any  user 
on  Digital's  internal  network. 

Compared  to  a  security  expert,  the  System  lile 
Protection  Inspector,  the  Password  Inspector,  and  the 
Mill net  Default  Account  Inspector  detected  the  kinds  of 
security  weaknesses  that  a  security  expert  would  find, 
.ho  User  Application  inspector  showed  that  it  is  quite 
capable  of  handling  t  lie  complexity  of  the  security 
aspects  of  an  application.  In  several  eases,  the  User 

Ajiji  i  n.  ,*  i  1UI1  I  ii.sjm.-x.  lui  UL'iuiai  V  i  0 1  <it  iOiiS 

that  were  missed  by  a  security  export. 


Site: 

Inspector  Name: 

Number  of  Nodes  Inspected: 
files  Inspected  per  Nodi:: 
Average  CPI)  Time  per  Node: 
Average  1. lapsed  Time  per  Node: 


XXX 

System  Pile  Protection 
I  n  spec  tor 
44 
(>2 

5.2  seconds 
1D7.1  seconds 


figure  4:  Performance  Statistics  for  t he  System  pile 
Protection  Inspector 


components  ot  XSAPP.  However,  we  tccl  that  the-  expert 
system  approach  has  provided  a  feasible  solution  to 
the  problem  of  obtaining  low-cost  medium- lev  el  security 
for  a  VAX/VMS  system  in  a  network  environment.  The 
performance  of  the  prototype  expert  system  is  very 
encouraging,  he  expect  that  the  VAX/VMC  user  community 
will  benefit  from  the  continued  development  ol  XSAPP. 
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Pigure  4  shows  some  p  ’•formanee  statistics  for  the  (l.andwchr  1981) 
System  File  Protection  In-  ctor. 

Figure  5  shows  some  performance  statistics  for  the 
PPCiK-t  Default  Account  Inspector. 


l.andwchr,  C.h. .  "formal  Models  for 
Computer  Security",  ACM  Computing 
SunvOi/4,  Vol.  13,  No.  3,  pp.  247- 
278,  Sep.  1981. 


5  PUT1IRP.  RPSh.Al’.CH  AND  CONCI.DS1  ON  (Neumann  1978) 

Purther  investigation  is  necessary  to  gather  more- 
heuristic  rule  for  the  Pxccutable  linage  Specialist. 

Primarily  these  rules  should  recognize  a  situation 

where  a  combination  of  certain  privileges  and  user  (Tcng  198Ca) 

functions  of  a  applieatiin  constitute  a  security  threat 

to  the  underlying  VMS  operating  system.  In  addition 

the  Program  Code  Specialist  needs  to  be  implemented  and 

tested. 


Site: 

Inspector  Name: 

Number  of  Nodes  Inspected: 
Average  CPU  'l  ime  per  Node: 
Average  I. lapsed  Time  pel'  Node: 


XXX 

The  DhCnct  Default 
Account  Inspector 
44 

6.5  seconds 
81  seconds 


(Teng  1986b) 


figure  5:  Performance  Statistics  lor  the  DhCnct  Default 
Account  Inspector 
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We  have  presented  an  expert  system  approach  lo 
computer  security  for  a  VAX/VMS  system.  Much  work 
remains  t;i  be  done  to  improve  and  complete  various 
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Abatract 

A  mathematical  formulation  describing  a 
telephone  switching  system  Is  required  to 
validate  Its  optrat.  Ion  In  a  mu  1 1  1  level 
communications  environment.  A  brief 
description  of  the  two  major  components  of  a 
telephone  switch  are  presented,  and  three 
systems  are  aescr Ibed  -  two  are  In  use  and  the 
third  Is  postulated.  A  mathematical 
description  of  a  security  policy  for  each  of 
these  systems  is  stated.  This  security  pel  icy 
val  idates  telephone  calls  between  system 
users.  A  discussion  of  the  reference  monitor 
concept  fol lows  and  provides  the  motivation 
for  applying  "Orange  Book"  standards  to 
telephone  systems.  The  formal Ities  appl i ed  to 
computer  systems  are  shown  to  apply  to 
telephone  systems,  the  obvious  advantage  Is 
that  system  capab i I Ities  can  be  Increased 
because  of  the  increased  trust  that  can  be 
placed  In  the  system. 


I ntroduot Ion 

Paralleling  the  combination  of  the 
computer  and  communications  fields  is  the 
merger  of  COMPUSEC  and  COMSEC  Into  a  broader 
dlsclpl I ne  -  INFOSEC.  The  ADD  community 
quickly  embraced  the  broader  Impl  ications  of 
INFOSEC,  however,  the  appl Icatlon  of  computer- 
related  INFOSEC  principles  to  classical 
communication  domains  is  still  limited. 

Within  these  domains,  the  unspoken  component 
of  INFOSEC,  OPSEC,  Is  considered  a  physical 
security  Issue.  The  app  I  i  c.a  t  I  or.  of  COMPUSEC 
formalities  and  requirements  to  communications 
systems  transfers  many  OPSEC  concerns  to  the 
system  hardware  and  software,  a  I  lowing  them  to 
arbitrate  system  use  in  a  mathematically 
consistent  and  verifiable  domain. 


Talaphona  Switching 

General  Description 

This  paper  discusses  secure  telephone 
systems  limited  to  single  sw itches  within  s 
closed  environment,  i.e.,  a  command  post.  The 
system  is  a  single  computer-control  led  device 
rather  than  a  network  of  devices.  This 
resti  i  c  t  Ion  si  rnp  M  f  i  as  the  treatment  and 
a  I  I ows  a  focus  on  the  key  point;  that 
telephone  switching  systems  are  amenable  to  £ 
mathematical  formal Izatiori  identical  to  that 
performed  within  ths  COMPUSEC  arena. 

Within  this  system,  the  major  components 

ar  e  : 

Station  Equipment  (Telephone):  A 
t r ansm i t ter / r ece i ver  which  converts  an 
accoustlc  signal  to/fro.n  an  electrical 
signal  arid  provides  and  responds  to 
control  signalling; 

Transmission  Medium:  The  electrical 

path  that  signals  traverse;  a  channel  or 


circuit  denotes  an  end-to-end  path  and 
the  path  between  station  equipment  and 
the  switch  Is  a  subscriber  loop  (or 
I  I  ne )  ;  and  a 

Switching  Device:  An  electrical  or 
electronic  device  which  physically 
connects  pairs  of  subscriber  loops. 

Overall,  two  distinct  but  Interrelated 
modules,  the  switching  network  arid  the  network 
controller,  perform  the  telephone  switching 
function.  A  set  of  switching  devices  (see 
above)  comprises  the  switching  network,  and 
the  network  control  I er  provides  the 
Intelligence  to  operate  the  individual 
switching  devices. 

Signal  I  i nq 

The  sequence  of  events  that  transpires 
during  a  normal  telephone  conversation 
Illustrates  the  relationship  be  tween  accous t I c 
and  control  signalling.  Following  is  a 
s imp llfled  description  ot  the  control 
signalling  necessary  to  support  a  telephone 
connection  and  the  Interaction  between  the 
network  controller  and  the  switching  network. 

1  .  The  cal  ler  requests  service  from  the 
switch  by  removing  the  telephone  handset 
from  Its  cradle  or  switch  hook. 

2.  The  network  control 'er  recognizes  the 
"off  hook"  condition  and  sends  a  dial 
tone  to  the  cal l er , 

3.  The  caller  dials  the  telephone  which 
transmits  the  called  station’s  address  to 
the  network  controller. 

4.  If  the  called  station  is  not  busy, 
the  network  controller  alerts  It  by 
sending  a  ringing  signal. 

5.  The  network  control  I er  provides 
feedback,  i.e.,  a  ringing  tone  or  a  busy 
signal  depending  on  the  status  of  the 
colled  station,  to  the  calling  station. 

6.  The  cal  led  party  accepts  the  cal  I  by 
'Ifting  the  handset. 

7.  The  network  control ler  reci  gnizes  the 
cal  I  acceptance,  terminates  the  r  inging 
signal  and  sends  the  cal  I  ing/cal  led  party 
add r ess -pa i r  to  the  network  control ler 
which  the  creates  an  accoustlc  signal 
path  (circuit). 

8 .  The  network  control  ler  mon I t  or  s  the 
connection,  releasing  It  when  either 
party  "hangs  up." 

Between  steps  *•  1  and  **7  ,  all 
co.nnun i ca t i ons  between  the  switch  and  either 
party  Is  control  signal  1  log.  Only  after  step 
a  7 ,  when  the  connection  Is  establ  Ished,  can 
accoustlc  signalling  take  place.  There  are 
different  techniques  for  separating  control 
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sequence  is  dependent  on  the  number  of  cal  Is 
i n  progress . 


and  accoust  ic  signalling;  among  them,  in-band 
signalling  and  above -band  signalling. 

(Control  signal  I  Ing  can  be  heard  dur  I ng  the 
set-up  time,  the  time  between  dialing  and 
ringing,  for  a  ‘ong-d Istance  telephone  call  or 
during  a  conversation  If  the  touch  tone  pad  is 
Inadvertently  decreased . )  Control  and 
accoust leal  signalling  use  the  same 
transmission  medium,  but  control  signals  are 
used  by  the  network  control  I  er  and  accoust  ic 
signals  are  routed  through  the  switch  network. 

Switch  Networks 

Although  the  network  controller  is 
central  to  this  paper,  I discussion  Is 
deferred  to  a  description  of  the  switch 
network  to  provide  a  more  complete  description 
of  the  entire  switch  system.  Virtual ly  al I 
telephone  Switching  is  circuit  switching,  that 
Is,  the  dedication  of  a  connection  between  a 
pair  of  subscriber  lines  for  the  duration  of 
the  call.  The  sw I tch  network  I s  compr i sed  of 
switching  devices  arranged  to  support  the 
simultaneous  connection  df  multiple  pairs  of 
communications  channels.  Modern  switch 
matrices  are  broadly  classified  as  space- 
division  or  t lme-d I v i s I  on  switches. 

Within  a  space-division  network,  a 
physical  I  ink  Is  establ  Ished  through  the 
network  to  connect  inu iv idual  subscriber 
I  ines.  The  network  appears  as  a  matrix  with 
each  Individual  subscriber  line  connected  to  a 
single  row  and  column  of  the  matrix. 

Shorting'  the  r  uwa  Situ  GO  I  ufiinS  at  the  5  r 
Intersection  creates  the  physical  connections 
within  the  network. 

Figure  I  represents  a  conceptual  space- 
division  network  with  switching  devices  at 
each  row  and  column  intersection.  In  this 
conceptual  representation,  each  switching 
device  corresponds  to  a  memory  location  in  the 
network  controller's  memory  space.  To  connect 
subscr 'ber  loops,  the  controller  uses  the 
origins  ing  and  destination  addresses  to 
a  Igor  i thm leal  I y  determine  the  memor  y  address 
of  the  switching  device  that  must  be  ’’set." 

Ir  the  simple  network  in  Figure  I,  to  connect 
subscriber  loops  A  and  B  requires  the  network 
controller  to  write  to  memory  location  Ofj. 


Subscriber 

A  0  t  0 


Accoust  Ic 
Signal 


from 

network- 

control 


Accoust  IC 
Signal 


Switching  Device 


Legend 

%ut>#cru*r  A  ->  line  *  i 
6  ->  *2 
C->  *3 

0>  mA 
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Figure  II  portrays  a  conceptual  design  of 
a  t lme-d 1 v I s I  on  switch.  The  network 
control  ler  places  the  cal  I  Ing/cal  led  address- 
pa  I  r  In  a  circular  queue,  and  circuitry  within 
the  network  matrix  cycles  through  the  queue, 
using  the  addresses  to  control  the  opening  and 
closing  sequence  of  the  gates.  In  the  simple 
network  of  Figure  II,  as  time  progress: 

At  1  1  ,  queue  entry  *♦  1  is  accessed  and 
gates  01  and  04  are  opened,  connecting 
telephones  A  and  D, 

At  T2,  queue  entry  *»2  Is  accessed  and 
gates  03  and  02  are  opened,  connecting 
telephones  C  and  B, 

At  T3,  queue  entry  **3  is  accessed  and 
recognized  as  an  I  nva  I  Id  address.  The 
network  circuitry  accesses  queue  entry 
1*1,  beginning  the  cycle  again. 

There  are  many  different  algorithms  to 
maintain  this  queue,  each  with  advantages  and 
disadvantages.  However,  regardless  of  the 
algorithm,  their  functional  behavior  is 
identical  and  easily  verified. 


Algor  I thm leal  I y , 

M  =  I  +  N  *  (O  -  1 )  where 

M:  Memory  location  of  the  switching 
dev  Ice, 

I :  Address  of  the  Incoming  I Ine , 

C:  Address  of  the  output  I ine,  and 
N :  Number  o  f  subscr I  bet  I  I nes 
connected  to  the  matrix. 

Writing  a  " 1 "  to  M  will  set  the  flip-flop  and 
complete  a  connection  between  the  two  parties. 
After  the  cell  Is  comp leted,  a  "0"  will  reset 
the  f  I  Ip-flop  and  disconnect  the  I  I  r»es . 

Within  a  t lme-d I v 1 3 i on  matrix,  the 
accoust  Ic  signals  being  transmitted  between 
subscr  I ber  loops  are  per  lodlcal  ly  broadcast  on 
a  common  bus.  Each  active  call  has  an 
assigned  "t Ime-alot,"  and  the  subscriber  I  oops 
are  connected  by  energizing  the  appropriate 
gates  when  the  time-slot  is  broadcast  on  the 
bus.  The  periodicity  of  the  ti me -s 1 o t 


Subscriber 


Fig.  II 

Uni  ike  the  t ime -d I v I  3 1  on  network,  whose 
data  stream  length  is  directly  proportional  to 
the  number  of  connections  being  supported,  the 
time -3  lot  Interchange  network  has  a  fixed 
length  data  stream  with  a  time-slot  for  each 
subscriber  line  connected  to  the.  swit*  h  At 
any  time,  the  contents  of  a  subscriber  Ine' s 


time-slot  depends  on  the  presence  of  accoustlc 
signal  I  ing  on  that  loop.  The  physical 
ordering  of  the  calling  and  called  parties' 
time-slots  are  Interchanged  when  they  are 
transferred  from  the  Input  to  the  output  data 
s  tr  earns  . 


Figure  I  I  I  portrays  a  conceptual  design 
of  a  time-slot  Interchange  switch  network. 

The  Input  stream  time-slots  ere  "filled"  and 
written  In  the  same  order  to  scratch  pad 
memory.  Input  time-slot  si  is  placed  In 
memory  01,  Input  time-slot  *2  Into  memo r>  02, 
Input  time-slot  n 3  Into  memory  03,  etc. 
Control  circuitry  computes  the  offset  between 
the  pair  of  time-slot  positions  for  each 
connection  and  this  dictates  the  access  order 
of  the  scratch  pad  memory.  A  connection 
between  subscr ibers  A  and  C  has  an  offset  of 
2.  The  network  switch  circuitry  would  copy 
memory  03  into  output  time-slot  **  1  ,  memory  02 
Into  output  time-slot  »2 ,  memory  01  into 
output  lime-slot  #3,  etc. 


Input  Data  Output  Data 


Stream  Stream 


Legend 

subscnoer  A  ->  time 

Slri* 

B  -> 

m2 

C-> 

•3 

D  -> 

•A 

Note.  Contentsor  lr*xjt  stream 
*1  and  2  are  interchanged 
without  output  stream 
*1  end  2 


Fig.  Ill 


Although  of  Increasing  complexity,  the 
hardware  descriptions  of  space-division  and 
time-division  networks  is  relatively 
straightforward,  as  are  the  algorithms  to 
translate  address-pa i rs  Into  control  signals. 
Their  behavior  Is  predictable  and  easily 
verified  using  Boolean  algebra.  The  concepts 
of  a  reference  monitor  and  security  kernal  do 
not  apply  to  the  switch  network  because  the 
network  controller  does  not  arbitrate  circuit 
connect  I ons . 


Network  Controller 


Current  generation  electronic  switches 
replace  wl  reci-  logic  with  software  to  provide 
network  control  functions.  Referring  to 
figure  IV,  the  central  processor  makes 
decisions  concerning  the  vft I Idlty  of  address- 
pairs.  The  control  I  er  transmits  the  adcJress- 
palr  to  the  Internal  switch  network  control 
circuitry  If  It  determines  that  the  address- 
pair  Is  va I  Id.  The  Input  signal  device 
(scanner)  is  the  device  through  which  the 
network  controller  receives  control  signalling 
on  the  Input  side.  The  memory  Is  used  for 
program  storage,  and  the  scratch-pad  memory  Is 
used  for  call  progress  Information.  The 
signal  distributor  on  the  output  side  serves 
the  same  function  as  the  scanner. 

Because  the  network  control  I er  makes  a  I  I 
decisions  concerning  address -pair  validity,  a 
formal  analysis  of  a  swltcl  netwoik  is 


excluded  from  the  following  descr  i  pt'i  on. 
However,  It  Is  impor  tant  to  understand  the 
relationship  between  the  switch  network,  the 
network  controller  and  control  and  accoust  ic 
signalling  to  fully  appreciate  the 
applicability  of  COMPUSEC  for  ma !  i t  I es  to 
secure  switching  systems. 


Fig.  IV 


S>cur I ty  Policy 
Pre I Iminary  Discussion 

The  conventional  COMPUSEC.  object,  l.e.,  a 
file,  does  not  exist  within  a  telephone 
switching  system.  It  Is  redefined  as  a 
subscr  iDer  line,  either  Inactive  or  active  In 
a  completed  circuit,  that  is  a  target  for  an 
Incoming  request.  Similarly,  In  a  telephone 
system,  "read"  access  corresponds  to 
monitoring  an  existing  conversation  and 
"write"  corresponds  to  a  broadcast  message, 
e.g.,  similar  to  a  public  address  system. 

The  Improper  accessing  of  a  file  or* 
process  in  a  computer  system  has  Its  paral lei 
in  a  telephone  system  as  a  m i sconnec t i on .  A 
misconnec ■ Ion  Is  the  connection  of  two 
subscribe.,  loops  (or  a  loop  and  r  circuit  for 
monitoring  or  broadcast)  whose  relative 
security  levels  do  not  meet  the  security 
po I  icy  or  that  violate  the  rules  for 
precedence  and  preemption  (an  in-progress  cal  I 
can  be  preempted  by  a  cal  I  of  higher 
pr  ecedence . ) 

There  are  two  9ource9  for  m I sconnec t I ons , 
an  error  In  the  algorithmic  processing  within 
the  switch  matrix,  or  a  logic  error  In  the 
network  controller  software.  An  example  of  an 
algorithmic  error  would  be  an  unexpected 
overflow  computing  an  address  offset;  although 
the  network  control  I er  va I  Idated  the 
connection,  the  Incorrect  offset  will  connect 
different  loops  then  Intended.  Algorithmic 
errors  are  pr I mar lly  engineering  pr ob I ems  and 
are  not  considered  In  the  fol lowing  treatment, 
although,  they  must  be  considered  during  a 
system  evaluation.  A  logic  error  In  the 
controller  software  results  In  a  rrilsconnect  Ion 
by  pr  ov I o Ing  an  Inva I  Id  address-pair  to  the 
switch  network  The  source  could  be  an  error 
in  the  database  that  describes  Individual 
subscriber  loop  characteristics,  or  an 
I mpr o per |y  expressed  condition  (i.e.,  " (A  or 

B)  and  C"  vice  "A  or  (B  and  C )  "  ) 
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The  0r  i  gma  I  system  descr  iptions  were 
prepared  with  an  emphasis  cm  expressing  state 
equat  ions.  Ilnl  ike  computer  systems,  a  user 
Can  not  change  the  security  levels  of  a 
subset  i  her  loop,  so  a  detailed  analysis  of 
state-changes  is  not  III um I na t I ng .  As  a 
result,  only  the  securlt/  policy  will  be 
descr  i  bed ,  the  state-change  equations  are  very 
S3 1  m  l  l  ar  to  those  descr  ibed  by  Bell  and 
LaPadu  I  a  . 

The  f o I  lowing  models  portray  three 
generations  of  switching  systems.  The  first 
and  second  are  now  In  uae;  the  first  Is  simply 
a  TEMf’CSTed  box  and  the  second  enforces  a 
mu  1 1  I  I evi  I  -  I  I  ke  security  policy.  The  third 
generation  is  postulated.  In  the  third 
generation  sw Itch,  overall  system  secur  i  t  y 
is  enhanced  and  the  system  includes  features 
not  currently  available  because  of  system 
limitations  and  the  limited  scope  of  security 
eva  i  nations. 

Pi  i  at  Generation 

The  first  generation  of  secure  switching 
systems  can  be  described  as  a  TEMPESTed  box. 
The  network  controller  does  not  enforce 
security.  In  other  words,  access  to  a 
telephone  Implies  authorization  to  connect 
with  any  other  suoscr  !  ber  I  ,ne.  Control  I  i  ng 
system  access  and  called  party  verification  is 
an  OPSEC  problem.  The  switch  supuorts  cal  I 
precedence  and  preemption. 

Expressed  In  conventional  set  notation, 

U  =  ( u  :  a  I  I  subscriber  lines  connected  to 

the  switch  network) 

S  =  Is  I aubscr I  her  I  I nes  originating 
cal  Is)  These  are  the  active 
entitles  In  the  system.  After  the 
circuit  Is  established,  both  lines 
(the  circuit)  are  potential  targets 
tor  preemption  and  are  again  treated 
as  objects. 

0  =  |o 1 subscr i ber  I  ines  receiving  cal  Is) 
These  are  the  passive  entities  in 
the  system, 

C  ci  P(0  x  O)  :  Set  of  active  circuits 
(ongoing  conversations). 

L  =  (II  set  of  secur  I  ty  and 

classification  levels;  S,  TS  and  TSC 
(compar  tmented  TS)) 

P  =  fplset  Of  precedence  and  preemption 
levels;  None,  Interrupt,  Priority, 
Plash,  Flash  Override)  A  circuit 
crested  without  a  preemption  level 
maps  to  a  P  (precedence)  of  "None." 

A  call  placed  without  a  preemption 
level  maps  to  a  P  (preemption)  of 
"None . " 

Both  L  and  P  are  connected. 

A  =  (alaccess  attributes;  connect  -  cj 

<  :  An  irref lexive,  ant  I symetr  i c , 

transitive  relation  "less  then.” 

-  :  A  reflexive,  symetrlc,  transitive 
relation  "equivalent  to." 

s  I  :  S.  0  ->  L,  a  function  mapping 
subjects  and  objects  to  their 
secur i ty  I  eve  I  . 

P I  ;  S  >  P,  a  function  mapping  subjects 
to  their  preemption  level. 

c_£  :  C  ->  p,  a  function  mapping  circuits 
to  their  precedence  level. 

and  ;  Logical  AND. 


Aoy  oCC  that  does  nor  meet  the  tol lowing 
condition  Is  a  mlsconnectlon; 

WseS.oEO, 

s,£,o  =>  si  (s)  -  sj^(o)  ar.g  cju(c)  <  p  I  ( s ) 

First  generation  systems  can  not  enter  a 
non-secure  state.  The  preemption  of  an 
existing  connect1 on  by  a  call  with  a  lower 
precedence  in.  the  only  possible  mlsconnectlon. 

Second  Generation 

Thi1  second  generation  system  has  the 
added  capability  cif  cl  assmar  k  I  ng  I  nd  I  v  I  dua  I 
subscr  i ber  I  i nes  with  a  secur  I  ty  I  eve  I  and 
enforcing  a  security  policy.  (Note,  this 
security  classmorklng  seems  to  be  enforced  as 
discretionary  access  rather  then  as  mandatory 
access.)  Access  types  ere  expanded  to  Include 
a  two-way  connection,  c;  and  one-way 
connections,  broadcast,  b  and  monitor,  m.  The 
switch  supports  precedence  end  preemption. 

The  difference  be  tween  this  security  policy 
and  the  first  generation  switch’s  is  that  the 
ordering  relation  on  L  Is  now  "less  then  or 
equal  to"  rather  then  an  equivalence.  In 
conventional  set  notation, 

U,  S,  0,  C,  L,  and  P  :  As  descr  I  bed 
a  bove . 

A  =  lalaccess  attributes;  connect  -  c, 
broadcast  -  b,  monitor  -  ml 

<  :  As  descr ibed  above. 

<  :  A  reflexive,  an t i syme tr i c . 

transitive  relation  "less  then  or 
equal  to" 

s  I  .  p  I  .  and  c_g  :  As  descr  Ibed  above. 

c  I  :  C  ->  L,  a  function  napDlng  circuits 
to  their  classification  level,  the 
Mln(aJ.(o  )  ..sKo^)  )  . 

Any  c6C  that  does  not  meet  the  following 
condltion(s)  is  a  mlsconnectlon: 

vse.oeo, 

s,c,o  =  >  s_l_  ( o )  £  3±  ( s )  and  cp  ( c )  <  £j_  • 3 ) 

s,b,o  =>  sj_(s)  <  <  (si(o)  ,<zj_(c)  )  and 
££>  (c)  <  p  I  (s) 

s,m,o  =>  (sj^  (o)  ,  cj_  (c)  )  <  s  I  (s) 

The  rationalization  for  this  policy  is  as 
follows.  A  subscriber  receiving  a  call  does 
not  receive  on  Indication  of  the  originating 
I  ine,  only  the  Incoming  I  Ine.  The  cal  led 
party  must  Insure  that  tbe  classification 
level  of  the  conversation  does  not  exceed  the 
security  level  of  hl9  circuit.  The  call 
originator  Is  responsibility  for  knowing  the 
security  level  of  the  called  party’s  line  and 
to  restrict  the  conversation  appropriately. 

A  security  policy  allowing  the  connection 
of  a  higher  to  a  lower  security  level  may  seem 
contrary  to  "normal"  computer  operations,  and 
obviously  provides  a  covert  channel.  The 
nature  of  a  telephone  system  is  two-way 
communications;  If  this  two-way  connection 
between  security  levels  Is  considered  "rom  an 
integrity  viewpoint  rather  then  a  strictly 
security  viewpoint,  It  Is  more  palatable.  The 
alternative  is  a  rigid  enforcement  of  security 
levels,  which  at  this  point,  seems  extreme. 
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Third  Generation 

The  third  generation  secure  switches  have 
expanded  capabl I Itles  and  features  and  can 
reduce  the  OPSEC  problem.  However,  there  Is 
an  Increased  demand  on  the  system  users.  In 
this  system,  subscriber  lines  are  not  passive 
entitles,  but  active  elements;  at  any  time, 
specific  users  are  associated  with  specific 
I  1 nes .  Essen t lally,  each  user  must  log  -  In 
before  using  the  system,  and  the  switch, 
through  access  control  I lats  (ACLs) ,  can 
enforce  both  system  and  specific  circuit  use. 

A  circuit  request  Is  redefined  as  an 
Interprocess  Invokatlon,  J_,  to  emphasize  that 
telephone  calls  are  now  be  tween  user /circuit 
combinations  rather  then  simply  between 
circuits-  Conventional  objects  now  exist, 
these  are  user  voice  mailboxes.  The 
voice  mailbox  Is  used  If  a  called  party  is 
busy,  and  the  calling  party  can  not,  or 
chooses  not,  to  Interfere  with  the  call. 
Security  control  of  mailboxes  Is  Identical  to 
that  of  any  object  In  a  secure  computer 
system,  the  contents  are  digltl.  _l  voice 
massages  rather  then  ASCII  strings. 

The  policy  for  voice  communications  is 
similar  to  the  above,  with  the  additional 
requirement  that  an  Individual  must  have 
specific  access  (d  lacret lonary  access!  to 
spec Iflc  circuits. 

U,  C,  L,  and  P  :  As  described  above. 

S  =  (slsubjacts;  system  users) 

0  —  {o. object s;  user  voice  mailboxes) 

I  P(S  x  S)  ;  Set  of  possible 
Interprocess  connection. 

A  =  (a: access  attributes;  Interprocess 
communication  -  (similar  to 
c  above) ,  broadcast  -  b, 
monitor  -  m,  read  -  r_ ,  write  -  w) 

<,  <  ;  As  described  above. 

3 1  .  p  I  .  cp .  cj  :  As  described  above. 

user  :  S  ->  U;  a  function  mapping 
subjects  to  users. 

ac  I  ;  S,  0  ->  P(U  x  A)  ;  a  function 
mapping  subjects  and  objects  to 
<user , A>  pa  I r s . 

name  :  U  x  A  ->  U;  a  function  selecting 
the  user  component  of  an  ACL  entry. 

mode  ;  u  x  A  ->  A;  a  function  selecting 

the  access  component  of  an  ACL  entry. 

As  above,  any  161  that  does  not  meet  the 
following  conditio'  is  a  mlsco enaction; 


s1  ,_l_,a0  * >  sj^(s2'  i  sUsj,  )  and 
C£(c)  <  J3_I_(Sj)  and 

t  ac I e  6  ac I  (Sg) 

wher  e 

name  -  user ( 3  )  and  mode ( ac I e )  =  J 

The  conditions  for  broadcast  and  monitor 
foil ow  logically,  as  do  the  conditions  for 
reading  and  writing  to  mailboxes.  The  use  of 
ACLs  allows  the  network  controller  to 
arbitrate  access  to  a  finer  granularity  then 
within  the  second  generation  switch,  a 
capability  particularly  desirable  for 
compar tmen ted  Information.  Because  access 


control  is  I Imlted  and  only  authorized  users 
(val Idated  by  the  switch)  can  make  and  receive 
calls  on  specific  circuits,  the  need  for 
OPSEC-or I en ted  authentication  proceedur e9 
( I . e . ,  voice  recognition)  is  eliminated. 

Voice  me  I  I  boxes  are  al  lowed,  because  they  are 
s imp  I y  files  on  a  computer  and  easily  proven 
secure . 


APPLICATION  OF  THE  "ORANGE  BOOK"  STANDARDS 

Reference  Monitor 

The  concept  of  a  reference  monitor  Is 
equal ly  appl (cable  In  a  secure  computer  system 
and  a  secure  telephone  switch.  Admittedly, 
there  Is  a  distinct  difference  between  a  one- 
direction  computer  message  and  a  telephone 
conversation,  but  the  reference  monitor's 
function  Is  to  enforce  a  formalized  security 
policy,  not  monitor  Information  flow.  Neither 
Is  a  specific  security  policy  Implied,  nor  Is 
the  Implementation  mechanism  relevent. 

The  reference  monitor  for  a  telephone 
switching  system  must  satisfy  three  logical 
properties;  1)  all  connection  requests  must 
be  mon Itored  and  the  security  policy 
(reflected  In  the  switch  database)  enforced, 

2)  the  reference  monitor  Is  unmodiflable  by 
common  users,  and  3)  It  has  provable  behavior. 

From  the  above  discussion  of  telephone 
switches,  It  Is  obvious  that  the  network 
controller  displays  the  first  two  properties, 
anu  state-change  functions  have  been  derived 
elsewhere  that  demonstrate  a  technique  for 
verifying  network  controller  behavior.  The 
behavior  of  the  switch  network  can  also  be 
verified.  Unfortunately,  there  appears  to  be 
little  on-going  effort  to  formally  prove 
consistent,  secure  behavior  within  the  current 
secure  switching  systems  -  the  purpose  of  this 
paper  Is  to  motivate  a  detailed  Investigation 
into  that  area. 

Orange  Book  Standards 

The  fundamental  computer  security 
requirements  described  In  the  Orange  Book  are 
1)  an  explicit  end  we ll-deflnsd  security 
policy,  2)  access  control  markings  associated 
with  system  objects,  3)  identification  of 
individual  subjects,  4)  system  auditing 
and  protection  of  information  on  secur  I ty 
related  actions,  6)  a  system  security 
enforcement  mechanism  capable  of  being 
analyzed,  and  6)  a  continually  protected 
secur I ty  enforcement  mechanism.  The  reference 
monitor  concept  Is  Inherent  In  these 
requirements.  The  security  keinal  Is  the 
hardware  and  software  real Ization  of  the 
reference  monitor  concept. 

The  switch  architecture  meets  al I  the 
above  criteria.  A  security  policy  has  been 
stated,  and  Is  reflected  In  the  switch 
database.  Switch  operation  requires  control 
markings  of  system  objects  (subscr Iber  I Ines) 
Although  lacking  In  the  first  end  second 
generation  switches,  the  third  generation 
switch  has  provisions  for  uniquely  identifying 
individual  subjects.  Current  generation 
switches  audit  ell  connections  and  all 
maintenance  actions.  Using  the  methodology 
outlined  in  Bell  and  LaPadu I e  end  elaborated 


on  above,  the  switch  enforcement  mechanism  can 
be  analyzed.  And  finally,  the  average  user 
can  not  directly  access  the  network  controller 
software,  which  continually  protects  and 
Isolates  the  security  enforcement  mechanism. 


CONCLUS ICN 

The  initial  motivation  for  applying  tne 
Orange  Book  standards  to  secure  telephone 
systems  was  an  analogy  between  the  telephone 
system's  physical  components  and  a  simple, 
multi-user  computer  system.  The  network 
controller  Is  analogous  to  the  computer  (CPU, 
memoryi  etc.),  the  switch  network  Is  analogous 
to  the  front-end  processor  and  the  telephone 
Instruments  are  analogous  to  the  terminals. 
Further  investigation  Into  switching  systems 
reinforced  the  analogy;  current  time-slot 
interchange  switches  even  packetize  the  voice 
tr  af  f  lc. 

The  primary  difference  between  telephone 
systems  and  computer  systems  is  that 
telephones  transmit  voice  traffic  (either  as 
analog  or  digital  signals)  and  computers 
transmit  ASCII  characters.  Also,  the  voice 
signals  never  enter  the  network  control ler  (or 
computer) .  However,  If  the  telephone  system 
Is  viewed  as  a  "black  box,"  Information 
enters,  Is  rerouted  and  exits,  Just  as  In  a 
computer  system.  The  same  basic  mathematic  I 
formalisms  and  evaluation  criteria  apply. 

The  advantages  of  using  the  Orange  Book 
evaluation  criteria  are  manyfold.  The  most 
obvious  are  the  ability  to  increase  the 
capabilities  and  services  of  the  telephone 
system  with  a  significant  measure  of 
confidence,  and  the  use  of  a  consistent,  well- 
defined  and  understood  evaluation  criteria  for 
system  certification. 
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Introduction 

Background 

The  Technical  Guidelines  Division 
of  the  National  Computer  Security 
Center  produces,  and  supports  others 
who  produce,  Computer  Security 
technical  guidelines  publications. 
The  purpose  is  to  provide  a  national 
computer  security  literature  base  that 
distributes  computer  security 
knowledge  and  techniques,  instills  an 
accepted  computer  security 
terminology,  and  applies  research  to 
practical  problems  of  computer 
security. 

The  National  Computer  Security 
Center  (NCSC)  has  working 
relationships  with  many  other 
organizations.  Their  support  and 
assistance  is  critical  to  the  overall 
success  of  the  technical  guidelines 
program.  The  Technical  Guidelines 
Division  is  a  service  bureau  in  many 
ways.  We  produce  work  required  by  our 
customers,  prioritized  according  to 
our  customers  needs  We  bring 
together  the  wisest  people  we  can 
find,  whether  from  the  private  sector, 
from  a  university,  or  from  another 
government  agency.  Our  coordination 
efforts  are  wide  and  constant.  The 
goal  is  to  produce  the  best  and  most 
usable  technical  guideline  possible. 
We  want  to  produce  guidelines  that  are 
easy  to  read  and  understand, 
unambiguous,  representative  of  all 
sectors,  and  helpful. 


The  purpose  of  this  article  is  to 
provide  an  update  on  the  status  of 
computer  security  technical 
guidelines.  Also  included  is  an 
explanation  of  the  levels  of 
guidelines  that  exist  and  how  they 
interrelate,  how  the  requirements 
process  works  that  kicks  off  new 
computer  security  technical  guidelines 
projects,  how  the  projects  are  done, 
who  is  involved,  and  what  the  future 
looks  like  for  Computer  security 
technical  guidelines. 


Scope 

The  scope  of  this  article 
includes  the  technical  guidelines  work 
done  at  the  NCSC  and  its  contributors 
in  the  private  and  civil  sectors  and 
the  academic  community.  Tne  project 
status  summary  (given  as  of  the  date 
of  the  presci  '  ation)  includes  the 
purpose  of  tlu.  individual  projects 
such  as  the  Trusted  Network 
Interpn  tation,  the  Trusted  Database 
Interpretation,  the  Trusted  UNIX 
Design  effort,  and  "How  To" 
guidelines. 

The  NCSC  and  the  Technical 
Guidelines  Division 

Why  Guidelines? 

Guidelines  are  not  thp  dictates 
of  a  government  agency!  They  arc  not 
intended  to  limit,  control,  or  in  any 
way  constrict  thinking  to  preset  hard 
ideas.  They  exist  to  document  a 
common  set  of  fundamental  principles 
of  computer  security.  They  also  are 
intended  to  serve  as  a  source  of 
common  language  and  approaches  to  help 
communicate  about  and  impiement 
computer  security. 

Specifically,  the  guidelines 
support  education  for  vendors,  users, 
and  evaluators.  They  greatly  reduce 
the  start-up  time  needed  when 
beginning  work  on  computer  security. 
The  guidelines  serve  as  tools 
themselves,  and  suggest  other  tools 
for  the  evaluation  and  implementation 
of  computer  security.  certainly  one 
of  their  most  valuable  uses  is  that 
they  spread  the  gospel  of  computer 
secux'ity  and  expand  the  cadre  of 
experts.  The  National  Computer 
Security  Conference  and  its  growth 
document  the  rapid  expansion  of  folks 
who  take  computer  security  seriously. 
The  guidelines  are  focal  points  of 
knowledge  concerning  computer  security 
on  specific  architectures  such  as 
trusted  networks  and  subsystems. 
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Wha^  Has  i)een  Happening ? 

The  Technical  Guidelines  Division 
at  the  NCSC  might  be  more  recognizable 
as  the  old  Standards  Division.  Since 
our  brothers  at  the  National  Bureau 
are  tasked  with  writing  standards  and 
the  NCSC  writes  technical  guidelines 
we  have  changed  the  organization 
title. 


required  in  a  specific  architecture 
for  it  to  be  trusted  at  defined 
levels.  The  criteria  and 
interpretations  also  contain  metrics 
that  designers,  evaluators,  and  users 
can  apply  to  the  features  in  an 
architecture  or  system  to  gauge  if  the 
required  computer  security  features 
are  indeed  included  and  work  as 
intended. 


As  Of  June  1987  the  NCSC  had 
produced  12  guidelines,  was  working  on 
nearly  30  additional  guidelines,  and 
had  identified  and  prioritized  more 
than  .70  additional. 

Note  that  the  large  "IDENTIFIED" 
area  in  Illustration  1  is 
disproportionately  larger  than  the 
number  in  it  when  compared  with  the 
other  slices  of  the  pie.  This  is 
because  there  are  many  more 
publications  that  are  yet  to  be 
identified.  Illustration  2  lists 

those  projects  that  have  been 
published  by  the  NCSC  as  of  June  1967. 


The  technical  guidelines  created 
at  the  NCSC  are  part  of  an  overall 
national  framework  for  computer 
security  technical  documentation. 
This  iidtioiidl  £1.  airfcjwoik.  ha» 

devised  to  assure  that  the  many  people 
and  organizations  interested  in 
computer  security  are  represented,  the 
required  technical  publications  are 
produced,  and  duplication  of  effort  is 
minimized- 

The  technical  guidelines  program 
has  two  levels.  They  are  the 
Evaluation  and  Design  Level  and  the 
Support  Level.  The  Evaluation  and 
Design  Level  is  a  level  of  high 
abstraction  and  truly  represents  the 
cutting  edge  of  computer  security 
technology.  In  Illustration  1  the  top 
level  represents  the  fundamental 
principles  of  computer  security. 
These  fundamental  principles  are 
derived  from  the  requirements  of 
computer  security  policy.  The  second 
level  is  the  criteria  and 
interpretations  level .  These  two  t.op 
levels  arc  the  Orange  Book  level  in 
that  the  original  Orange  Book  was  made 
up  of  the  fundamental  principles  of 
computer  security  and  the  criteria  for 
the  evaluation  of  a  stand-alone 
operating  system. 

Now  the  technical  guidelines 
program  is  creating  new  criteria  and 
interpretations  for  the  evaluation  and 
design  of  trusted  networks, 
subsystems,  database  management 
systems,  distributed  systems,  and 
tactical  and  embedded  systems.  The 
criteria  and  interpretation 
publications  detail  the  features 


There  are  technical  "How  To" 
books  and  administrative  "How  Tc" 
books.  The  technical  "How  To"  books 
are  intended  to  flesh  out  how  to  use 
the  metrics  and  features  discussed  in 
the  criteria  and  interpretation  level 
guidelines  for  the  different 
architectures.  For  example,  how  does 
one  do  configuration  management  for  a 
trusted  network?  The  administrative 
"How  To"  books  will  look  at  non- 
technical  assistance  such  as  "How  to 
Begin  an  Evaluation  with  the  National 
Computer  Security  Center". 

The  most  important  project 
recently  underway  at  the  NCSC  is  the 
Trusted  Network  Interpretation.  This 
guideline  is  essential  in  that  the 
nation  is  building  systems  based  on 
network  architectures  and  will  expand 
these  efforts  in  the  future.  There  is 
a  large  effort  now  towards  building 
secure  networks.  The  trend  towards 
building  architectures  with  widely 
distributed  w’orksf a t ions ,  servers,  and 
users  creates  special  needs  for 
increased  security.  In  fact,  we 
compare  working  on  the  Trusted  Network 
Interpretation  with  a  mini  manned 
space  shot  --  the  work  is  very  complex 
and  terribly  difficult,  every  step  is 
completely  new  ground,  and  there  is 
absolutely  no  room  for  error. 

At  the  Support  Level  of  the 
technical  guidelines  program  there  are 
many  players.  For  example  the 
National  Bureau  of  Standards 
contributes  much  of  its  Federal 
Information  Processing  System 
Standards  to  this  level.  The  NCSC' 5 
project  on  a  Trusted  UNIX  Design  is 
also  at  this  level. 

The  Requirements  Process 

The  requirements  process  that 
establishes  a  technical  guideline  as  a 
project  is  not  complex.  Initially  the 
project  planning  process  was  driven  by 
the  needs  of  the  evaluators  as  defined 
in  the  Management  Plan  that  governs 
all  evaluations  at  the  NCSC.  The 
Management  Plan  specified  guidelines 
to  compliment  the  work  of  the 
evaluators  and  system  designers.  When 
the  orange  Book  was  the  sole  criteria 
and  stand-alone  systems  were  the  only 
systems  being  evaluated  this  was 
simple  enough.  But  the  complexity 
introduced  by  beginning  evaluations  on 
trusted  networks,  subsystems,  and  in 
the  future  a  broad  range  of  system 
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architectures  mandated  more  structure. 
As  discussed  earlier  the  different 
levels  of  technical  guidelines  have 
evolved  and  now  each  level  of  that 
structure  has  x-oqui  rements . 

Now,  too,  there  are  new  peop]  e 
and  organizations  involved  in  computer 
security  and  they  have  their  own 
special  needs.  The  "How  To"  hooks 
become  increasingly  important  as  more 
interested  persons  get  involved  -  many 
of  whom  have  limited  experience  with 
Computer  security  and  evaluations. 
The  expanding  number  of  architectures 
being  evaluated  requires  more  criteria 
and  interpretations  to  be  written. 

Now  we  must  insure  that  all  have 
a  chance  to  participate  in  the 
requirements  process.  He  have  begun 
writing  articles  for  publication  that 
will  reach  the  new  and  old  players  and 
invite  their  suggestions  for  new 
guidelines  or  recommend  changes  to  old 
ones.  This  paper  is  part  of  that 
process.  I  invite  you  to  forward  your 
ideas  and  suggestions  to  the  Technical 
Guidelines  Division  at  the  NCSC. 
Suggestions  will  go  to  the  Technical 
Guidelines  Review  Board  which  has  been 
established  for  this  purpose.  All 
suggestions  will  get  responses. 

SfittingjrioriSiss 

Obviously  «  piobleiu  is  evolving. 
Where  are  the  resources  to  produce  all 
of  the  technical  guidelines?  Which 
guideline  is  most  urgently  needed? 
Who  has  the  most  critical  need  for  a 
technical  guideline  to  address  their 
problem?  Certainly  there  are  few 
expex'ts  around  to  lead  these  efforts. 
The  growing  number  of  technical 
guidelines  requirements,  the  success 
of  computer  security  as  reflected  by 
the  awakening  of  a  national  will  for 
computer  security,  and  the  staggering 
increase  in  the  number  of  systems 
being  built  with  computer  security  in 
mind  tax  the  previously  serial 
production  of  guidelines. 

Now  clearly  we  must  carefully 
assign  priorities  to  projects  based  on 
national  need  and  the  greatest  impact. 
The  priority  list  is  developed  by  the 
Technical  Guidelines  Division  after 
gathering  inputs  from  many  sources. 
At  the  end  of  this  talk  we  will  give 
you  a  survey  to  fill  out  that  will 
help  us  in  our  priority  planning  as 
well  as  in  our  quality  assurance 
program.  This  is  one  of  a  number  of 
efforts  we  have  underway  to  determine 
what  our  priorities  should  bo. 

How  projects  are  pone 

The  development  process  that 
results  in  a  guideline  can  be  quite 
varied  depending  on  the  technology 
being  documented.  Some  of  the  factors 
that  determine  the  process  are  who  is 


going  tc  lead  the  work,  who  is  going 
to  do  the  work,  when  is  the  guideline 
needed,  and  how  much  money  is 
available? 

In  general  the  development 
process  begins  with  a  scorch  of  the 
existing  literature  and  an  exploration 
into  who  knows  the  most  about  the 
subject  The  issues  that  must  be 
addresed  and  solved  are  determined  and 
solidified.  Then  a  dialogue  is 
initiated,  usually  in  person,  by  phone 
and  through  DOCKMASTFR.  All  of  this 
interaction  results  in  an  issues  paper 
that  is  intended  to  serve  as  the  basis 
for  a  guideline.  The  issue  paper  is 
also  the  strawman  that  generates 
comments  from  interested  parties. 
From  the  comments  the  scope  and 
specific  intent  of  the  future 
guideline  can  bo  determined.  The 
project  manager  can  generate  a  tasking 
plan  that  will  assign  a  whole  document 
or  parts  of  a  document  to  those  who 
will  be  the  authors.  Then  the  authors 
synthesize  the  total  research  to  that 
point  into  a  draft  guideline.  The 
drafts  are  published  for  review  ar.d 
comment;  first  to  a  small  group  of 
very  knowledgeable  reviewers,  and  then 
later  to  a  more  general  audience.  At 
last,  the  guideline  will  be  published. 

Project  Status 

Illustration  S  shows  the 
technical  guidelines  program  timelines 
as  of  June  1987  for  the  projects 
coordinated  by  the  ncsc.  The  project 
is  listed  in  the  year  that  it  will  be 
completed.  Note  that  some  projects 
are  underway  now  even  though  they  are 
not  scheduled  for  completion  until 
FY90.  Clearly  these  projects  are 
tough  and  require  long  lead  times  for 
research  and  maturation.  The 
asterisks  indicate  that  the  project  is 
underway. 

Future  Projects 

The  guidelines  requirements 
through  the  year  1990  are  pretty 
clear.  Obviously,  some  guidelines  are 
much  more  difficult  than  others. 
Among  the  most  difficult  are  the 
tactical  systems  guidelines  and  the 
embedded  systems  guidelines.  While 
they  are  not  scheduled  for  publication 
until  the  1990  period  we  have  begun 
our  investment  in  them  and  we  are  in 
the  literature  research  phase  of  the 
preparation  cycle. 

Illustration  6  shows  that  the 
greatest  numbei'  of  publications 
underway  in  the  1980  through  1990  time 
period  are  in  the  "How  To"  series. 
These  are  the  guidelines  that  the 
evaluators,  designers,  and  users  will 
use  most  in  their  daily  work.  The 
numbers  of  "How  To"  books  will  grow 
significantly  as  the  criteria  and 
interpretation  level  guidelines  are 
produced. 
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Conclusions 


The  technical  guidelines  program 
has  a  key  role  in  the  development  ol 
computer  security.  It  provides  the 
library,  for  computer  security  work. 
It  gives  us  a  common  language  and  a 
common  view  of  the  computer  security 
world.  Even  if  wo  disagree,  it 
provides  us  something  to  disagree 
about  with  reference  points  and 
metrics  for  discussion.  It  is  in  tho 
technical  guidelines  that  we  codify 
our  understandings  of  tho  science  and 
it  is  here  that  we  merge  our  ideas 
about  how  to  secure  new  architectures. 
This  is  where  we  look  ahead. 


TECHNICAL  GUIDELINES 


ILLUSTRATION  l 


WHAT  HAS  BEEN  WRITTEN? 

•  TRUSTED  COMPUTER  SYSTEM  EVALUATION  CRITERIA  -  1983 

•  TRUSTED  COMPUTER  SYSTEM  EVALUATION  CRITERIA  -  1985  (DoD-STD) 

•  COMPUTER  SECURITY  REQUIREMENTS  -  1985 

•  RATIONALE  BEHIND  THE  COMPUTER  SECURITY  REQUIREMENTS  -  1985 

•  PASSWORD  MANAGEMENT  GUIDELINE  -  1985 

•  NETWORK  WORKSHOP  PROCEEDINGS  ■  1985 

•  MAGNETIC  REMANENCE  -  1985 

•  TRUSTED  NETWORK  EVALUATION  CRITERIA  -  1985  (DRAFT) 

•  “COMPUSECese”  COMPUTER  SECURITY  GLOSSARY  -  1985  (EDITION  1) 

•  PERSONAL  COMPUTER  SECURITY  CONSIDERATIONS  -  1985 

•  DATABASE  MANAGEMENT  SYSTEMS  SECURITY  WORKSHOP  PROCEEDINGS  -  1986 

•  A  GUIDELINE  TO  OFFICE  AUTOMATION  SECURITY  -  1987 


ILLUSTRATION  2 
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DESIGN  AND  EVALUATION  LEVEL 


SUPPORT  LEVEL 


ENCOURAGE 

COORDINATE 

DEVELOP 

EMBRACE 


TECHNICAL  REPORTS 


INFERENCE  V 


SUPPORT  GUIDANCE 


— —  />UTOM.*nntj  RFitmEMCeV**^ 


DEVELOP 

EMBRACE 
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DEVELOPMENT  PROCESS 

•  LITERATURE  RESEARCH 

•  DETERMINE  ISSUES 

•  INITIATE  DIALOG 

•  DEVELOP  ISSUE  PAPER 

•  SOLICIT  COMMENTS 

•  DEFINE  SCOPE 

•  TASK  FCRCs/CONSULTANTS 

•  SYNTHESIZE 

•  REVIEW/COMMENT 

•  TECHNICAL  REVIEW  BOARD 

•  PUBLISH 


ILLUSTRATION  4 
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TECHNICAL  GUIDELINES  PROGRAM 
DEVELOPMENT  SCHEDULE 


FY67 


FY88 


FY89 


♦TRUSTED  NETWORK  INTF.RP 
-NCSC  CHANGE  BOOK 
♦CONFIGURATION  MGNT 
♦CIVIL  SECTOR  ENVIRON 
♦WORKING  WITH  THE  NCSC 
•DAC 
♦AUDIT 

♦REVISED  MAGNETIC  RENI 
♦QUALIFIED  PRODUCTS  LIST 
♦Glossary 

CRITERIA  REVIEW  BOARD-CTD 
OFFICE  AUTOMATION-CTD 


♦SUBSYSTEMS  INTERPRET 
♦TRUSTED  UNIX  DESIGN 
•SYSTEM  ARCHITECTURE 
•DESIGN  DOCUMENTATION 
♦LABELING 

•COVERT  CHANNEL  ANALYSIS 
•TRUSTED  FACILITIES  MANUAL 
•DAA  ACCREDITATION  GUIDE 
•MAC 

•NETWORK  TESTING  I30LN 
SSO  GUIDELINES 
SYSTEM  INTEGRITY 
SECURITY  TESTING 
PRODUCT  DISTRIBUTION 
SECURITY  FEATURES  GUIDE 
TRUSTED  PATH 
PRIVATE  SECTOR 'ENVIRON 
•DECLASSIFICATION  SOFTWARE 


•DBMS  INTERPRETATION 
TEST  PLANS  &  DOCUMEN 
DESIGN  SPECS  &  VERIF 
HDW/FMW  VERIFICATION 
SOFTWARE  VERIFICATION 
SECURITY  MODELS 
AIS  INSPECTION  GUIDE 
AI3  STANDARD  PRACTICE 
OBJECT  REUSE 
TRUSTED  FACILITY  MGNT 
TRUSTED  RECOVERY 
ELECTRONIC  MAIL  PRIVACY 


•PRODUCT  ACQUISITION  GUIDE 


*  INDICATES  PROJECT  UNDERWAY 


ILLUSTRATION  S 


FY9Q 


DISTRIBUTED  PROCESSING 
IDENT.  *  AUTHENTICATION 
•TACTICAL  SYSTEMS 
•EMBEDDED  SYSTEMS 
INSIDER  THREAT 
SECURITY  MODEL  INTERPRET 
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SUPPORT 

DOCUMENTATION 

HOW  TO  BOOKS 

CRITERIA 

TECHNICAL 

REPORTS 

TRUSTED  UNIX  DESIGN 

SYSTEM  ARCHITECTURE 

TRUSTED  NETWORK  INTERPRET. 

CIVIL  SECTOR  ENVIRONMENTS 

DESIC-N  DOCUMENTATION 

NCSC  ORANGE  BOOK 

WORKING  WITH  THE  NCSC 

CONFIGURATION  MANAGEMENT 

SUBSYSTEMS  INTERPRETATIONS 

OAA  ACCREDITATION  GUIDE 

TEST  PLANS  &  DOCUMENTATION 

DBMS  INTERPRETATION 

OFFICE  AUTOMATION 

LABELING 

DISTRIBUTED  PROCESSING 

SSO  GUIDELINES 

COVERT  CHANNEL  ANALYSIS 

TACTICAL  SYSTEMS 

PRIVATE  SECTOR  ENVIRON. 

TRUSTED  FACILITIES  MANUAL 

EMBEDDED  SYSTEMS 

DECLASSIFICATION  SOFTWARE 
PEVISE  MAGNETIC  REMANENCE 
QUALIFIED  PRODUCTS  LIST 
CRITERIA  REVIEW  BOARD 
GLOSSARY 

PRODUCT  ACQUISITION  GUIDE 

D4C 

MAC 

network  testing  guidelines 

DESIGN  SPECS/VERIFICATION 

AUDIT 

SYSTEM  INTEGRITY 

INSIDER  THREAT 

AIS  INSPECTION  GUIDE 

AIS  STANDARD  PRACTICE 
ELECTRONIC  MAIL  PRIVACY 

SECURITY  TESTING 

PRODUCT  DISTRIBUTION 

SECURITY  VERIFICATION 

SECURITY  MODELS 

IDENT  AND  AUTHENTICATION 

OBJECT  REUSE 

TRUSTED  FACILITY  MANAGEMENT 
TRUSTED  RECOVERY 

SECURITY  MODEL  INTERPRETATIONS 

AS  OF  15  APR  87 
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GETTING  ORGANIZATIONS  INVLCWED  IN  OCMPUIER  SECURITY: 
THE  HQI£  OF  SECURITY  AWAHEtESS 
by  Elizabeth  Markey 
Chief  ,  Policy  and  Awareness  Division 
Office  of  Information  Systems  Security 
Bureau  of  Diplcmatic  Security 
U.S,  Department  of  State 


Objectives  of  Presentation 

To  learn  hew  bo  get  organizations  aware  and 
involved  in  catiputer  security  through  on-going 
training  and  awareness  programs  aimed  at  employees 
at  all  levels. 

Background 

U.S-  Department  of  State  automated  information 
systems  are  used  at  over  150  diplcmatic  and 
consular  posts  wrldwide  for  word  processing  , 
financial  disbursements  and  controls  ,  personnel 
functions  ,  issuance  of  passports  and  visas  ,  and 
other  inportant  management  functions.  Because  of 
the  sensitivity  of  many  of  these  systems  ,  their 
security  is  being  given  increasing  emphasis  by 
State  Department  management.  Responsibility  for 
automated  information  systems  security  has  been 
assigned  to  the  office  of  Information  Systems 
Security  (1SS)  of  the  Bureau  of  Diplcmatic  Security  , 
but  ISS  cannot  do  the  job  alone.  The  effectiveness 
of  the  systems  security  program  depends  to  a  great 
extent  on  the  participation  of  other  elements  of 
the  State  Department.  ,  particularly  managers  ,  line 
security  personnel  ,  and  users. 

Currently  ISS  is  conducting  a  series  of 
seminars  and  briefings  aimed  at  employees  at  all 
levels  which  include  tire  following: 

1)  A  2-hour  briefing  for  Executive  Directors 
of  our  regional  and  functional  bureaus  in 
Ukj  Department; 

2)  A  4-day  seminar  for  Regional  Security 
Officers  (RSOs)  .  who  are  responsible  for 
security  at  our  overseas  embassies;  and 

3)  A  1-2  hour  briefing  for  all  new  employees 
with  the  Department. 

The  objective  is  to  ensure  tliat  all  employees 
are  up-to-date  on  ccrputer  teclinologies  used 
throughout  tbe  Department  ,  and  have  tile  information 
needed  to  participate  effectively  in  the  Department 
of  State  oatputer  security  program. 

Basic  Messages  Conveyed 

These  systems  security  seminars  and  briefings 
are  tailored  to  meet  the  varying  levels  of 
knowledge  ,  experience  ,  and  responsibilities  of  all 
employees. 

Tlic  briefings  for  Executive  Directors  stress 
the  potential  consequences  arising  fran  the  lack 
of  adequate  protection  of  the  organi?.ation's 
telecommunications  and  automated  information  systems 
resources  ,  and  the  caimitnent  of  the  organization 
to  protect  automated  systems  resources.  Executive 


Directors  are  briefed  on  current  National  and  State 
Departnxait  system  security  policies  and  standards  , 
as  wall  as  potential  threats  and  vulnerabilities 
cf  our  systems.  The  main  objective  here  is  to 
ensure  that  ccrputer  security  in  the  Department 
first  and  foremost  receives  support  from  top 
management. 

The  4-day  saninars  for  Regional  Security 
Officers  contain  much  more  in-depth  information. 

Por  exairple  ,  officers  learn  enough  about  lew 
Department  of  State  ccrputer  systsns  function  to  be 
able  to  ZAP  a  passvrord  file  ,  browse  a  user's 
directory  of  files  ,  and  monitor  the  activities  of 
the  Systan  Administrator.  The  goal  is  to  give  the 
officer  a  good  understanding  of  the  technical 
aspects  of  automated  information  systems  bo  know 
where  and  why  security  vulnerabi  litres  occur-  ,  and 
hrw  to  detect  and  correct  them.  Second  ,  this 
seminar  includes  four  "hands  on"  lab  sessions  using 
a  Wang  VS  ooiputer  system.  These  sessions  enable 
each  officer  to  try  out  the  ideas  presented  in  the 
first  part  of  tlie  seminar  at  a  ccrtput.er  terminal. 

Tire  officers  learn  word  and  data  processing 
capabilities  ,  password  administration  ,  and  hew  to 
spot  potential  weaknesses  in  the  system.  In  the 
third  part  oi  the  seminar  ,  the  officers  arc  briefed 
on  current  St-:  te  Department  automated  information 
systems  ,  security  policies  ;ind  standards  ,  and 
potential  threats  to  the  systems.  The  emphasis 
here  is  on  the  practical  application  of  the  first 
two  parts  of  the  seminar  to  the  actual  conditions 
wliich  security  officers  will  encounter  at  overseas 
State  Department,  posts. 

Briefings  are  also  held  for  all  new  employees 
before  they  begin  their  employment  with  the 
Department.  Virtually  all  of  these  new  employees 
will  become  users  of  our  automated  information 
systems.  For  the  most  part  ,  these  briefings  stress  , 
in  non-technical  terms  ,  the  threats  and  vulnerabili¬ 
ties  of  departmental  systems  and  hew  ccrputer 
security  inpacts  than  directly.  We  also  give  users 
instructions  on  how  to  protect  the  integrity  of  tlx: 
carputor  and  the  information  that  goes  into  and 
out  of  it.  The  focus  here  is  on  "do'£'  and  "don't”  . 
Finally  ,  we  stress  why  the  user  sliould  be  concerned 
with  good  security  practices  and  how  they  should 
react  to  potential  problem  situations. 

Each  seminar  and  briefing  has  been  carefully 
structured  to  support  our  overall  objective: 
continued  effsetive  participation  by  all  enployees 
in  the  systems  security  progr.  Evaluations  by 
participants  ,  and  later  feedbu,  K  confirm  that  these 
briefings  and  seminars  are  meeting  this  objective. 

lessons  Learned 

In  1987  ,  automated  information  systems  security 
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must  be  part  of  every  aiployec's  job.  The  computer 
security  unit  in  a  large  organization  cannot  hope 
to  cover  ail  bases  by  itself.  The  experience  with 
tire  State  Department  systems  security  seminars 
and  briefings  has  shown  tint  oiployccs  at  all 
levels  can  participate  actively  in  supporting 
systems  security  goals.  But  tliere  are  tw>  important 
prerequisites.  Systems  security  policy  and 
procedures  must  be  carefully  delineated.  It  is 
essential  that  basic  policy  objectives  ,  and  specific 
security  procedures  be  constructed  to  support  the 
mission  of  the  organization  ,  and  that  the  policy 
has  the  support  of  line  organizations.  This 
requires  all  concerned  parties  to  have  a  hand  in  the 
policy  review  and  approval  cycle.  Likewise  ,  the 
rcspcinsibi litres  of  each  unit  of  the  organization 
must  be  veil  defined.  Tile  Office  of  Information 
Systems  Security  lias  followed  this  path  in  the 
publication  of  four  detailed  automated  information 
system  security  standards  which  have  been  adopted 
by  the  Department  of  State. 

Although  these  points  are  generally  understood  , 
training  aril  awareness  activities  nay  not  always 
receive  tie  attention  they  deserve.  Ccnputer 
operators  and  technicians  may  feel  that  systems 
concepts  are  too  exmplex  to  be  grasped  by  "non¬ 
technical"  people.  The  State  Department  experience 
has  shown  tint  this  is  not  so.  Of  course  ,  training 
goals  must  be  set  realistically.  An  analysis  of 
tlie  published  security  responsibility  assignments 
will  slww  exactly  what  each  arployee  needs  to  know 
to  do  the  job  assiyned  to  them.  T  f  the  content 
of  the  training  is  sharply  focused  on  these  needs  , 
it  will  be  apparent  to  the  audience  ,  and  they  will 
be  motivated  to  apply  themselves  and  atisorb  idle 
material.  Once  they  gain  confidence  in  their 
ability  to  deal  with  oenputer  security  matters  , 
they  will  becare  active  participants  in  the 
automated  information  systems  security  program. 

The  development  and  conduct  of  ccnputcr 
security  training  and  awareness  activities  is  not 
a  simple  task.  A  substantial  investment  in  time 
by  the  systems  security  unit  is  required .  However  , 
the  resulting  contributions  by  the  organization's 
employees  will  repay  the  effort  nuny  times  over. 
Managers  ,  line  security  people  ,  and  end  users  with 
the  proper  training  and  support  can  nugnent  the 
eyes  and  ears  of  tire  systems  security  unit  , 
contribute  expertise  ir.  physical  s  ecurity  and 
investigation  of  security  incidents;  in  short  help 
to  build  a  team  effort:  to  strengthen  av.taiutod 
systems  security. 
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The  Computer  Security  Training 
Base  of  1985 

Eliot  Sohmer 

National  Computer  Security 
Center 

In  August  1985  the 
Director  of  the  National 
Computer  Security  Center  (NCSC) 
established  a  special  task 
force  consisting  of  six  senior 
Center  personnel.  The  task 
force  was  the.  result  of  the 
Director's  recognition  that 
there  was  no  established 
curriculum  of  computer  security 
(COMPUSEC)  courses  and  that 
Center  personnel  possessed  a 
wide  range  of  capabilities  and 
vastly  different  knowledge 
bases.  The  task  force's  job 
was  to  assess  the  situation  and 
make  recommendations  to  the 
Director  for  corrective  action. 


The  task  force,  led  by 
Eliot  Sohmer,  chief  of  the 
Office  of  Product  Evaluations 
and  Technical  Guidelines  within 
the  NCSC,  issued  its  final 
report  and  recommendations  on 
24  October  1985.  The 
recommendations  of  the  report 
were  accepted  and  are  now  being 
implemented  by  the  Center. 

Ultimately,  the  training 
laid  out  in  the  plan  will  be 
made  available  to  anyone 
interested  in  receiving  it.  We 
will  start  by  training  Center 
personnel.  Our  plan  is  to  fit 
the  courses  together  into  a 
coherent  whole  so  that  the 
material  "flows"  from  concept 
to  concept.  We  will  then  video 
tape  the  training  and  make  the 
tapes  available  to  other 
government  agencies, 
universities,  and  vendors. 

The  task  force's  final 
report  identified  nine 
categories  of  Center  personnel 
ranging  from  product  evaluators 
to  research  and  development 
specialists  to  clericals  (see 
enclosure  1) .  We  included 
clericals  and  administrative 
assistants  to  increase  their 
awareness  of  COMPUSEC  issues  so 
all  Center  personnel  could  work 
as  a  team  in  this  adventure 
called  the  "COMPUSEC 
revolution. " 

The  task  force  identified 
eighteen  courses  we  believed 
were  needed.  Of  these,  twelve 
were  non-tcchnical  and  six  were 


technical  (see  enclosure  2)  . 

We  then  built  a  matrix  that 
enabled  us  to  recommend  to  the 
Director  which  of  the  nine 
categories  of  employees  should 
take  which  of  the  eighteen 
training  modules  (see  enclosure 
3)  • 

The  task  force  also 
produced  a  summary  of  what  we 
thought  would  be  appropriate 
information  to  include  in  each 
module  (see  enclosure  4) .  In 
so  doing,  we  gave  a  curriculum 
committee  a  head  start  in 
putting  together  the  courses. 

Since  the  final  report  was 
issued,  the  Office  of  Technical 
Support  within  the  NCSC  has 
taken  the  initiative  and 
developed  or  supervised  the 
development  of  most  of  the  non¬ 
technical  courses.  The  Center 
is  now  in  the  process  of 
developing  all  of  the  technical 
courses.  A  seventn  course,  one 
on  penetration,  has  since  been 
added  to  the  technical 
offerings. 

Finally,  the  task  force 
also  developed  a  suggested 
"road  man"  detailing  a  logical 
sequence  in  which  personnel 
could  be  guided  through  various 
parts  of  this  program  (see 
enclosure  5) . 

I  believe  the  task  force's 
work  and  the  subsequent  effort 
within  the  Center  to  implement 
its  recommendations  will  have 
long-term,  significant  effects 
on  the  National  Computer 
Security  program.  The  training 
material  developed  wi) 1  help 
many  sources  such  as 
universities,  government 
agencies,  computer 
manufacturers,  and  the 
evaluation  community  to  develop 
consistency  in  their  approaches 
to  COMPUSEC. 


THE  NINE  CATEGORIES  OF  CENTER 
PERSONNEL:  (Enclosure  1) 

I.  Product  evaluator 

II.  System  evaluator 

III.  R&D  specialist 

IV.  Technical  implementation 
specialist  -  an  engineer 
working  on  implementing 
computer  security,  such  as 
BLACKER  personal 
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V.  Manager  -  some  individuals 

may  be  required  to  take  modules 
identified  for  this  category, 
as  well  as  for  another  category 
(example:  a  supervisor  who  is 

also  a  systems  evaluator) 

VI.  Trainer  -  individual  who 
works  with  Center  education  and 
awareness  programs 

VII.  support  -  basically, 
non-technical  personnel  who  do 
not  fall  into  one  of  the  other 
categories  (e.g.,  C13  and  C23 
personnel ) 

VIII.  Administrator  - 
individuals  in  personnel 
administration  and  other 
primarily  staff  functions 

IX.  Clerical 


LIST  OF  TRAINING  TOPICS 
(Enclosure  2) 

Non-Technical  Courses: 

1 .  Orientation  to  Computer 
Security  Issues: 

Standard  terminology  and  basic 
concepts,  Lines  of  Defense, 
Threat  and  Vulnerability 

2 .  Center  Organization  and 
Mission; 

Center  Organization  and  Major 
Activities,  The  Center  Within 
NSA,  Within  DoD  and  within 
the  Federal  Government 

3 .  Our  Fundamental  Beliefs  and 
Policy... The  Catechism 

4 .  Pol i cy.  Directives, 
Regulations,  and  Legalities: 
NTISSC,  SAISS  roles; 

Other  directives  and 
regulations  as  appropriate 

5 .  Fundamentals  of 
Classification : 

Covei names,  codewords, 
compartmentation,  etc. 

6 .  Ethics  and  Responsibility 
of  Center  Personnel : 

Computer  Usage  (in  general  and 
as  an  individual) 

Government  employees' 
responsibilities 

7 .  Measuring  Computer 
Security : 

Introduction  to  Criteria, 
Standards,  and  Guidelines 

8 .  Criteria  Part.  II: 

Cl-Bl;  B2 ;  B3-A1 


9.  Evaluating  the  Environment- 
An  overview 

10 .  visk  Management 

1 1 .  Admini stration_pf  Computer 
S r-cnr itv  in  an  Org animation . 

12 .  COMSEC  Overview 


13.  Architectures: 
implementation  issues, 
Technical  credibility  of  an 
implementation,  Show  how 
specific  architectures  either 
support  Criteria  or  not 


14 .  The  Criteria  (Technical 
Version!; 

philosophical/policy 
underpinnings;  - 

Derivation  of  requirements  from 
"first  principles": 

Structure  of  Criteria; 

Main  elements  of  each 
division/class  (object  reuse, 
mandatory  controls  and 
labeling,  formal  methods); 

Inter-dependence  of 
requirements; 

Relationship  of  documentation 
required  for  above 


1 5 .  Theoretical  Foundations 

introduction  to _ L°d t d- 

Policy  Mode ling : 

Basic  concepts  -  modeling, 
access  control  mechanisms, 

€  t  c  •  * 

Bell-La  Padula,  information 
flow,  non-inference,  multilevel 


16.  Model  Interpretation: 
Translation  of  higher  levels  of 
abstraction  into 
hardware/software  design; 
Assurance  that  implementation 
rules  of  policy  model 


17.  correctness: 

Specifications 

Metatheorems 

implementation  Correctness 
Formal  semantics  of  Programming 
languages 

predicate  Transformation 
Correspondence  itiappmg . 

Issue  of  formal,  unambiguous 
specification  languages. 

Issue  of  information  flow 
(covert  channel  analysis) 
and  invariant  analysis; 
Implementation  Capabilities  and 
limitations  of  technology; 

Tools  developed  to  apply 
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theory;  fundamentals  of  Hoare 
logic 

18 .  Evaluation  Theory  and 
Practices: 

Examination  of  theoretical 
underpinnings  of  the  three 
major  classes  of  the  criteria 
and  how  modeling  and  assurance 
concepts  are  embodied  in  each. 


TRAINING  TOPICS/PERSONNEL 

CATEGORIES 

(Enclosure  3) 

1.  orientation  to  CS  Issues 

Student  hours :  10 

Personnel  Categories: 

All 

2.  Center  Organization/Mission 
Student  hours:  1 
Personnel  Categories: 

All 

3.  Fundamental  Beliefs 
Student  hours:  2.5 
Personnel  Categories: 

I,  II,  III,  IV,  V,  VI, 

VII 

4.  Policy,  Dir,  Regs, 
Legalities 
Student  hours:  3 
Personnel  Categories  - 

II,  V,  VI,  VII (1) 

5.  classification 
Student  hours:  1 
Personnel  Categories: 

1(2) ,  11(2) ,  111(2) , 

IV ( 2 ) ,  V ( 2 ) ,  VI ( 2 ) , 

VII ( 2 ) ,  VIII (2 ) ,  IX(2) 

6.  Ethics/Responsibility 
Student  hours:  4 
Personnel  Categories: 

All 

7.  Measuring  Computer  Security 
Student  hours:  1.5 
Personnel  Categories: 

I,  II,  III,  IV,  V,  VI,  VII, 
VIII 

8.  Criteria  II 
Student  hours:  3 
Personnel  Categories: 

I,  II,  III,  IV,  V,  VI,  VII 

9.  Evaluating  the  Environment 
Student  hours :  1 
Personnel  Categories: 

II,  V,  VI,  VII(l) 

10.  RisK  Management 
Student  hours:  1 
Personnel  Categories: 

II,  V,  VI,  VII(1) 

11.  Administration  of  Computer 


Science 

Student  hours:  1 
Personnel  Categories: 

II,  VI. 

12.  COMSEC  Overview 
Student  hours :  2 
Personnel  Categories: 

I,  II,  III,  IV,  V(l) , 

VI,  VII,  VIII(1) ,  IX(1) 

13.  Architectures 
Student  hours:  20 
Personnel  Categories: 

I,  II,  III,  IV,  V(l) , 

VII(l) 

14.  The  Criteria  (tech  version) 
Student  hours:  20 
Personnel  categories: 

I,  II,  III,  IV,  V(l) , 

VII(l) 

15.  Theoretical  Foundations 
Student  hours:  60 
Personnel  Categories: 

I,  II,  III,  IV,  V(l), 

VII (1) 

16.  Model  Interpretation 
Student  hours:  16 
Personnel  Categories: 

I,  II,  III,  IV,  V(l) , 

VII(l) 

17.  Correctness 
Student  hours:  60 
Personnel  Categories: 

I,  II,  III,  IV,  V(l), 

VII (1) 

18.  Evaluation  Theory  and 
Practices 

Student  hours:  40 
Personnel  Categories: 

I,  II,  III,  IV,  V(l) 

(1)  job-specific;  may  be 
required 

(2)  required  only  for  new 
hirees  or  others  with 
insufficient  experience  in 
dealing  with  classified 
materials 

totaIjS  : 

1-13 ,  11=17,  111=13,  IV=13 , 

V=9,  VI=11,  VI1=7,  VIII=4,  1X=3 

PERSONNEL  CATEGORIES: 

I  =  product  evaluator 

II  =  system  evaluator 

III  =  R&D  specialist 

IV  =  technical  implementation 

specialist  (BLACKER) 

V  =  manager 

VI  =  trainer 

VII  =  Gupport 

VIII  =  administrator 

IX  =  clerical 
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DESCRIPTION  OF  TRAINING 

MODULUES 

(Enclosure  4) 

TOPIC:  1.  Orientation  ta 

Computer  Security  Issues 

TIRE  FOR  STUDENT  TO  COMPLETE: 

10  hours 

SUMMARY  OF  MODULE:  Basic 
Theme:  What  is  really  going  on 

when  a  computer  works;  break 
the  "hallucination"  syndrome 

1.  Standard  Terminology  and 
Basic  Concepts 

A.  How  a  Computer  Works 

3.  Computer  Subversions 

Trojan  Horse 
Trap  Door 

Time  Bomb  (Logic  Bomb) 

Data  Diddling 
Salami  Technique 
Superzapping 
Virus 

The  results  of  these 
subversions : 

Destruction  (Denial  of 

Service) 

Alteration  of  Data 
Disclosure  of  Data 
Delay  (Down  Time) 

c.  Definitions 

Access  Control 
Controlled  Sharing  (not  in 
COMPUSECese) 

Reference  Monitor 
Security  Kernel 
Trusted  Computing  Base 
System  High  operations 
Dedicated  operations 
Controlled  Operations 
Multilevel  operations 

2.  Lines  of  Defense 

A.  Physical 

Various  devices  to  prevent 
theft,  damage,  or  destruction 
to  a  computer  facility  or  its 

components . 

List  devices 

Give  major  problems  and 

examples 

B.  Personnel 

Measures  taken  by 
management  to  ensure  that 
employees  in  ADP-related 
positions  are  both 


knowledgeable  and  trustworthy 
in  matters  of  computer 
security. 

List  measures 
Give  major  problems  and 
examples 


The  means  of  ensuring  that 
information  passing  through 
communications  channels  is 
protected  from  unauthorized 
access  and  interpretation. 

Describe  areas  of  concern; 
Explain  method  of  protection 
( cryptography) 

D.  Emanations 

Way  of  ensuring  that  our 
electronic  equipment  does  not 
radiate  signals  that  can  be 
collected  by  an  adversary. 

Describe  problem 

Explain  method  of  protection 

E.  Operational  Procedures 

Policies  and  rules  that 
ensure  that  actual  practices  in 
the  computer  facility  or  area 
adhere  to  principles  of 
security. 

Automated  audit  and 
individual  accountability 

List  recommended  procedures 

Describe  operational 
environments  using  secure 
procedures. 

F.  Trusted  Computer  Systems 
(TCS ) 

Components  of  a  TCS  - 
namely,  hardware,  software,  and 
configuration  control  -  provide 
enough  protection  to  ensure 
that  a  range  of  classified  and 
sensitive  information  can  be 
processed  simultaneously 
without  danger  of  compromise. 

Define  hardware,  software, 
and  configuration  control. 
Describe  briefly  how  these 
areas  can  be  protected  or  are 
evaluated. 

3.  Threat  and  Vulnerability 

Threat  -  external  and 
internal 

B.  Vulnerability 
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(1)  Mainfiamo  Vulnerabilities 

The  vulnerabilities  we  are  most 
concerned  about,  those  that  may 
occur  quite  frequently.  Most 
of  these  frequently  occurring 
vulnerabilities  are  present 
because  security  was  not  a 
design  issue.  Wo  can  group 
these  recurrent  vulnerabilities 
into  three  categories.  The 
first  category  is  the  improper 
use  of  technology;  this 
category  includes : 
insufficiently  trained 
operators,  poor  applications, 
data  entry  errors,  and 
improperly  designed  multiuser 
connections.  The  second 
category  encompasses 
vulnerabilities  generated  by 
weak  or  non-secure  operating 
systems.  These  include  trap 
doors  left  by  system 
developers,  easily  gained 
super-user  (super-zapper) 
status,  and  microcode/assembly 
language  manipulation  of 
operating  system  controls.  The 
third  category  of 
vulnerabilities  are  improper 
access  controls  such  as  poor 
log-on  procedures,  weak 
passwoid  management,  and 
trivial  audit  procedures. 
Through  the  use  of  a  trusted 
computer  system  many  of  these 
vulnerabilities  can  be 
alleviated. 

(2)  Personal  Computers 
Hardware  Security  Concerns 

A.  Theft  and  Damage 

B.  Equipment  Aids 

C.  Environmental  Controls 

D.  Magnetic  Media 

-  Information  Security  Concerns 

A.  Theft  and  Damage  of  Data 

B.  Contamination  of  Data 

Software  Security  concerns 

A.  Piracy 

B.  Risks  of  borrowed  software: 
viruses  and  integrity  issues 

-  Communications  Concerns 

TOPIC:  2.  Center  Organization 

and  Mission 

time  for  student  to  COMPLETE: 

1  hour 

SUMMARY  OF  MODULE: 


review  of  the  Center 
organization  to  division-level 
and  a  brief  description  ol  the 
activities  in  each  entity.  The 
discussion  will  also  show  how 
the  Center  fits  within  NSA, 

Don,  and  the  Intelligence 
Community.  Our  special 
national  mission  will  also  bo 
explained,  and  how  the  Center 
carries  out  this  mission 
through  the  NT1SS1C  structure 
will  be  addressed. 

(Must  be  taken  before  Module 
#3) 

TOPIC:  3.  our  Fundamental 

Beliefs  and  Policy... The 
Catechism 

TIME  FOR  STUDENT  TO  COMPLETE: 

2 . 5  hours 

SUMMARY  OF  MODULE: 

The  employee  will  first 
read  the  Cate  '  ism  and  then 
participate  i  i  discussion  of 
these  issues,  which  will  be  led 
by  a  senior  Center  policy 

The  catechism  discussion 
forum  will  be  held 
approximately  once  a  quarter . 

(Module  #2  is  pre-requisite) 

TOPIC:  4.  Pol i cy , _  Directives / 
Reciulations  ,  and  Legal  j.ties 

TIME  FOR  STUDENT  TO  COMPIJSTE: 

3  hours 

SUMMARY  OF  MODULE: 

An  hour  lecture  will 
highlight  the  significant 
features  of  those  directives, 
regulations,  and  other 
documents  which  govern  security 
in  the  Federal  Government. 
Appropriate  DoD  and  OMB  policy 
and  implementation  documents 
will  be  examined  in  detail. 
After  the  lecture,  copies  of 
the  referenced  documents  will 
be  made  available  for  the 
students'  study,  with  guidance 
from  the  supervisor  on  which 
documents  are  most  germane  to 
the  students'  work. 

TOPIC:  5.  Fundamentals  _o£ 

classification 

TIHE  FOR  STUDENT  TO  COMPLETE: 

1  hour 


This  module  will  contain  a 
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SUMMARY  OF  MODULE: 

The  briefer  will  review  the 
fundamentals  of  the  DoD 
classification  syutum. 
Specifically,  the  briefing  will 
include  the  NSA  Act  of  1959  and 
a  review  of  public  Law  86-36. 
The  four  types  of  protected 
information,  need-to~know,  and 
the  classification  categories 
will  be  discussed.  Covernames 
and  codewords  will  be  defined 
and  the  reason  for  them  will  be 
explained. 


topic:  6.  Ethics  and 
^Responsibilities  of  Center 
Personnel 

TIME  FOR  STUDENT  TO  COMPLETE: 

4  hours 

(2  hours  of  reading,  1  hour  of 
videotapes,  1  hour  of 
discussion) 

SUMMARY  OF  MODULE: 

I.  computer  Usage  (in  general 
and  as  an  individual) 

A-  Responsibility  Defined  - 
legal  and  security  requirements 

B.  Issues  in  a  Computer 
Information  Society 

Unauthorized  access 
Ownership  of  Information 
Giving  one's  password  to  an 
unauthorized  user 
Privacy 

Copywrite  violation  or  piracy 
0-  The  Center  as  a  Showcase 

II.  Government  Employees' 
Responsibilities 

A.  NSA,  Don,  and  Government 
standards  of  conduct  and 
related  rules  and  regulations 

B.  Our  Relationship  with 
Non-Government  Organizati:  ns 

1.  DoD  Community  Relations 
Program 

a.  Objectives 

b.  Policies 

2.  Participation  in 
commercially  sponsored 
conferenccs/symposia 

3.  Participation  in  activities 
of  private 

oryanizati ons 

4.  Providing  information  to 


non-Gove rnment 
orgaui zationo 

5.  Dealing  with  contractors 

-  gi fts 

-  unfair  advantage 

C.  Handling  of  Sensitive 
(Unclassified)  Information 

1.  Sensitive  Information 
Defined 

a.  Unclassified  info  which 
may  be  protected  by  T.L.  86-36 

b.  Information  protected  by 
PL  93-579,  the  Privacy  Act 

2.  Responsibilities  for 
protecting  sensitive 
information 

a.  Physical  Protection 

b.  Need  to  know 

c.  Privacy  Act  Restrictions 

1 .  The  Law 

2.  Internal  Rules 

D.  Handling  Proprietary 
Information 

111.  The  Media;  Publication 
Procedures 

A.  Release  of  Unclassified 


Information 

1.  Written  information: 

a. 

presentations 

b . 

school  Papers 

c . 

books 

d. 

personal  records 

G  . 

logos 

f  . 

buoiness  cards 

2.  Central  point  of  control 
necessary  to: 

a.  Oversee  cumulative 
effect  of  information  leaving 
Agency 

b.  Coordinate  with  secdef, 
DoD,  and  others,  as  appropriate 

c.  Serve  best  interests  of 
Agency 

3.  Procedures  for  requesting 
release 

B.  Media  inquiries 

1.  Central  point  of  control 
nocessary  as  in  (A)  above 

2.  Procedures  for  handling 

a.  Verbal  inquiries 

1.  telepno:  3  inquiries 

2.  inquiries  received 
during  conferences,  symposia, 
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otc.  .  . 

b,  Written  inquiries 
IV.  Behavior  of  a  Center 
Representative 

A.  Code  of  Ethics  for 
Government  service 

1.  Matters  of  ethical  conduct 
include: 

a.  Business  and 
Professional 
Activities 

b.  Bribery  and  Graft 

c.  Gratuities 

d.  Contributions  or 
Presents  to  Superiors 

e.  Use  of.  Government 
facilities,  Property 
and  Manpower 

f.  Use  of  Civilinn  and 
Military  Titles  in 
Connection  with 
Commercial  Enterprises 

g.  Outside  Employment 

h.  Gambling,  Betting  and 
Lotteries 

i.  Personal  Indebtedness 

2.  Responsibilities  of 

3.  Responsibilities  of 
Managers 

B.  Conflicts  of  Interest 

1.  Major  Prohibitions 

2.  Non-Disqualifying 
Financial  Interest 

3.  Procedural  Requirements 


TOPIC:  7.  Measuring  computer 

Security 

TIME  FOR  STUDENT  TO  COMPLETE: 

1  i/2  hours 

SUMMARY  OF  MODUl£: 

The  purpose  ol  this  module 
is  to  acquaint  new  employees 
with  the  purpose  and  thrust  of 
the  criteria,  how  it  fits  into 
the  Center's  mission,  and  its 
utility  as  an  inrtrument  of 
policy.  This  module  is 
basically  intended  for 
non-technical  staff,  and  thus 
will  not  delve  into  the  details 
of  Criteria  requirements. 
Although  come  of  the  material 
will  parallel  that  given  in  the 
Criteria  module  for  technical 
personnel,  it  will  generally  be 
presented  in  considerably  loss 
depth.  The  student  should  be 


left  with  an  understanding  of 
what  the  Criteria  is  about,  its 
uses,  and  its  import. alien  to  the 
Center  and  Center  policy  and 
technical  dirocticnc. 

a.  Develop  the  Need  for 
a  Criteria:  This  section  is 
dosigned  to  load  the  student  to 
an  appreciation  of  the 
experiences,  problems,  and 
solutions  that  led  to  the 
attempt,  to  write  the  criteria, 
and  thuB  load  the  student  to  an 
appreciation  of  the  value  of 
the  Criteria.  Basically,  the 
discussion  should  proceed  as 
follows: 

-  DoD  experience  with 
"custom-built"  systems;  the 
problems  of  non-common 
terminology,  non-common 
perception  and  artieul ation  of 
requirements,  all  oi  which 
leads  to  expensive  systems 
which  still  may  not  provide  the 
level  of  security  desired. 

-  Utility/purpooo  of 
the  Criteria;  provide  common 
understanding  of  the 
fundamental  security  issues, 
provide  a  common  terminology, 
and  provide  a  common  yardstick 
for  measuring  and  comparing 
security  "goodness." 

b.  Derivation  From 

Tolicy:  This  section  is 

designed  to  lead  the  student  to 
an  understanding  of  the  issues 
the  Criteria  addreosos,  and  why 
it  addresses  those  issues.  It 
should  be  approached  from  the 
direction  of  "Let's  design 
computer  security  criteria." 
Selections  from  relevant 
national  policy  should  bo 
presented.  This  should  be  in 
"plain  English"  as  opposed  to 
DoD  jargon.  The  idea  1g  to 
demonstrate  the  need  to  derive 
retirements  from  basic  policy 
statements,  and  to  develop  the 
Criteria  control  objectives. 

The  student  will  be  introduced 
to  the  basic  concepts 
underlying  the  Criteria,  such 
as  policy  enforcement  (to 
include  DAC  and  MAC), 
individual  accountability,  and 
auditing.  The  student  should 
be  led  to  an  appreciation  of 
the  place  of  each  control 
objective  in  overall  security 
fabric . 

c.  Structure  of  the 
Criteria:  The  purpose  of  this 
section  is  to  develop  a 
familiarity  with  the  D  through 
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A1  terminology,  where  it  comes 
from,  and  what  it  means.  The 
structure  of  the  Criteria  will 
be  presented  as  a  scale  for 
measuring,  with  essentially  no 
details.  Major  distinctions 
between  the  Criteria  divisions 
will  be  characterized. 

d.  Uses  of  the  Criteria: 
Re-emphasize  the  two  basic  uses 
to  which  the  Criteria  are  put, 
basically? 

-  As  a  tool  for  determining 
system  security  requirements. 

-  As  a  yardstick  for 
measuring  security  "goodness" 
of  products. 

Each  of  these  should  be 
discussed  in  the  context  of  the 
Center  missions  they  support. 

e.  The  Criteria  in  Derail: 
In  this  section  the  student 
will  be  taken  on  a  detailed 
tour  of  each  Criteria  division 
and  class.  Each  division  will 
be  characterized,  and  then  the 
specific  requirements  of  each 
class  will  be  discussed. 

Because  this  section  is 
specifically  intended  for  those 
who  require  extensive  knowledge 
and  deeper  appreciation  of  the 
Criteria,  observations  relevant 
to  implementation 
choices/dif f iculties  are 
appropriate.  The  results  of 
Criteria  interpretation,  as 
well  as  any  insights  gained 
from  the  interpretation  process 
(i.e.,  difficulty  of  applying 
the  Criteria  to  some 
situations,  e.g.,  VMM)  will 
also  be  presented.  The 
"breakpoints"  (i.e.,  B1/B2, 
B2./B3)  will  be  studied.  Also, 
evaluation  issues  and 
implications  will  be 
incorporated  into  the 
presentation  (e.g.,  what  is 
sufficient  evidence  to  support 
the  requirements  for  formal 
specification  and 
verification?)  . 


TOPIC:  8.  Criteria  Part  II  - 

The.  Reauiremsnca  of  Each  Class 

TIME  FOR  STUDENT  TO  COMPLETE: 

3  hours 

SUMMARY  OF  MODULE: 

This  sub-modulo  is  designed 
for  the  person  who  needs  or 
desires  more  detail  on  the 
technical  content  of  the 
Criteria.  It  is  expected  that 


this  material  will  be  presented 
primarily  to  educators  and 
managers.  The  material  is  a 
prerequisite  for  this 
sub-module.  The  student  should 
be  left  with  an  understanding 
of  how  the  Criteria  move  from 
an  emphasis  on  features  to  an 
emphasis  on  assurance,  some 
understanding  of  the  details  of 
the  various  classes  and 
divisions  of  the  Criteria,  and 
an  appreciation  of  how  the 
Criteria  also  serve  as  an 
instrument  of  Center  policy. 

a.  Structure  of  the 
Criteria:  Should  start  with  a 
somewhat  more  thorough  tracing 
of  the  Criteria  from  rationale, 
basic  principles,  and  the 
reference  monitor  concept,  all 
of  which  are  derived  from  basic 
policy  statement  ..  Here  it  is 
desirable  to  show  which 
documents  state  which 
requirements.  Some  of  the 
basic  concepts  can  be  expanded 
upon,  notably  MAC  and  DAO 
mechanisms,  getting  into  more 
detail  as  to  the  policy 

awu  iiu^jiuiUtillUcluion 

implications.  Additionally, 
other  concepts,  such  as  Trojan 
horse  and  covert  channels,  can 
be  introduced.  The  details  of 
the  Criteria  will  be  presented 
as  follows: 

-  Cl  through  Bi  will  be 
addressed  as  a  group,  noting 
that  the  architectural/ 
assurance  requirements  are 
similar  across  these  classes. 
Discussion  of  each  of  these 
classes  in  detail,  showing  the 
progress  from  one  class  to  the 
next  higher  one.  Distinguish 
between  mechanisms  (e.g.,  DAC) 
and  assurance  items  (e.g., 
object  reuse) .  Note  that  the 
emphasis  is  largely  upon  the 
addition  of  mechanism,  thus  the 
Center  view  that  it  is  possible 
to  "grow"  a  Bl  system  from  a  D 
system  merely  by  adding 
features . 

-  B2  Systems:  will  be 
presented  as  a  separate 
subject,  noting  the 
distinguishing  characteristics 
of  this  class.  The  student 
should  be  left  with  an 
understanding  of  the 
requirements  for  basic  system 
structure  and  architectural 
support  for  security  that 
underlie  this  class.  The 
student  should  understand  these 
aspects  of  the  requirements  as 
the  beginnings  of  real 
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assurance,  noting  that  at  this 
juncture  in  the  criteria  the 
emphasis  changes  from  adding 
mechanism  to  adding  the 
assurance.  B2  is  the  first 
levei  in  which  we  arc  assured 
that  a  reference  monitor 
function  is  credibly 
implemented. 

-  B3  and  A1 ;  also  to  be 
presented  as  a  unit,  noting 
that  Al  is  architecturally 
equivalent  to  B3  (i.e.,  no  new 
features  are  added) .  The 
strengthening  of  the  top-down 
design  requirements  and  demand 
for  more  thorough  architectural 
support  should  be  explored,  and 
examples  from  the  criteria 
presented. 

b.  Relation  to  Policy  and 
Strategy:  Here  we  state  the 
Center  position  that  we  will 
always  specify  ADP  system 
security  requirements  in  terms 
of  Criteria  ratings  (vice  the 
"Chinese  menu"  approach) . 
Discuss  how  this  is  consistent 
with,  and  in  fact  follows  from, 
the  Center  mission  to  make 
improved  products  widely 
available  in  the  marketplace. 
Discuss  the  "chicken  a:  c  egg 
dilemma,"  and  what  is  being 
done  to  address  it  (e.g.,  the 
EPL,  influencing  the  KFP 
process,  national-level  policy, 
environments  document,  etc) . 
Discuss  the  export  control 
issues,  noting  the  Center 
position  as  well  as  the  current 
status  of  the  U.S.  export 
control  policy.  Explore  what 
steps  the  Center  is  taking  to 
continue  to  encourage  vendors 
to  cooperate.  Can  also  discuss 
here  how  the  Criteria  is  a  tool 
in  determining  the  RSD 
directions.  The  basic  thrust  of 
this  section  is  to  leave  the 
student  with  an  understanding 
of  the  Criteria  as  a  document 
which,  derived  from  basic 
policy  statements,  articulates 
fundamental  security 
requirements.  Thus  it  also 
serves  as  an  instrument  of 
Center  policy  and  a  guiding 
tool  for  charting  future 
directions . 

TOPIC:  9.  Evaluating  the 

Environment 

TIKE  FOR  STUDENT  TO  COMPLETE: 

1  hour 

SUMMARY  OF  MODULE: 

The  rationale  behind  the 


Center  Environments  document 
will  be  discussed,  especially 
the  development  of  the  Risk 
Index.  Then  some  real-world 
examples  of  how  to  apply  the 
recommendations  in  the  document 
will  be  discussed. 

TOPIC:  10.  Risk  Management 

TIME  FOR  STUDENT  TO  COMPLETE: 

1  hour 

SUMMARY  OF  MODULE: 

Risk  management  is  the 
identification  of  risks  to  an 
organization's  information 
resources  through  an  analysis 
of  information  assets,  threats, 
and  vulnerabilities. 

Key  terms  which  must  be 
understood  are: 

asset 

threat 

vulnerability 

risk 

loss 

safeguard 

The  module  will  cover  the 
purpose  ot  risk  management  and 
the  methods  involved  in 
conducting  a  risk  analysis 
project.  An  example  will  be 
presented  which  will  illustrate 
this  process. 


TOPIC:  11.  Administration  of 

a.  Comuu ter  Security  Program  in 
an  Organization 

TIME  FOR  STUDENT  TO  COMPLETE: 

1  hour 

SUMMARY  OF  MODULE: 

This  module  describes 
security  program  management, 
considerations .  It  consists  of 
basic  guidelines  for 
establishing  and  managing  a 
computer  security  program. 
Specifically,  these  topics  are 
covered : 

1.  Elements  of  a  good 
computer  security  program 

2.  Pitfalls  to  Avoid 
for  Managers 

3 .  Senior  Management 
Duties  in  a  Computer  Security 
Program 

4 .  Internal  Control 
Considerations  for  Managers 
3.  Audit  Function 
Considerations 

6.  Making  Deliberate 
Business  Decisions 

7.  Balancing  Technology 
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and  Human  Issues 

0.  Setting  and 

Implementing  Goals  -  Managerial 
Considerations 

9.  Managing  Computer 
Employees 

10.  Making  Computer 
Security  Work 


TOPIC:  12 .  COMSEC  Overview 

TIME  FOR  STUDENT  TO  COMPLETE: 
2  hours 


SUMMARY  OF  MODULE: 

This  topic  is  meant  to  give 
the  student  an  appreciation  of 
the  COMSEC  threat  and  some 
countermeasures  that  can  be 
used.  Some  basic  concepts  of 
encryption,  including  the  DES , 
will  be  covered. 

A  variety  of  videos  and 
readings  will  be  available.  The 
exact  videos  to  be  viewed  will 
be  determined  by  the  employee's 
supervisor,  selecting  those 
most  germane  to  the  employee's 
job. 


For  example,  clerical 
personnel  may  benefit  most  from 
material  emphasizing  the 
vulnerabilities  of  telephones 
and  other  office  systems. 


TOPIC:  13.  Architectures 

TIME  FOR  STUDENT  TO  COMPLETE: 
20  ..ours 


terminology,  and  mechanisms. 
Various  architectures  will  be 
described,  such  as 
descriptor-based,  stack,  and 
object-oriented  systems. 
Additionally,  memory  management 
and  process  management 
strategies  will  be  explored. 

b.  Models  of  Protection 
Mechanisms:  Lampson's  Access 
Matrix  model  will  be 
presented.  The  notion  of 
domains,  objects,  access 
privileges,  and  rules  for  their 
manipulation  will  be  presented 
as  examples  of  operational 
models  of  the  Access  Matrix 
model.  The  student  should  be 
left  with  an  understanding  of 
the  issues  of  domain  isolation, 
authorization  of  domain  access 
to  objects,  the  transfer, 
revocation,  and  review  of 
access  privileges  between 
domains,  as  well  as  the 
creation  and  destruction  rules 
for  both  domains  and  objects. 

c.  Architectural 
Support  for  Domains  of 
Protection:  Various 

inltji. pi'etat ions  of  the  domain 
model  are  considered,  which 
lead  to  descriptor  and 
ring-based  protection 
mechanisms,  capability-based 
systems,  storage-key  and 
privileged-mode  protection 
mechanisms,  domain  call -return 
mechanisms,  and  stack  frame 
protection.  Each  of  these  will 
be  related  to  the  issues 
identified  above  (i.e.,  domain 
isolation,  etc.) 


SUMMARY  OF  MODULE: 

The  purpose  of  this  module 
is  to  provide  the  student  with 
an  understanding  of  the  major 
computing  architectures,  and 
especially  how  protection 
mechanisms  are  incorporated 
into  hardware  and  software 
systems.  It  will  provide  the 
basis  upon  which  to  build  an 
understanding  of  the 
architectural  and  design 
implications  of  the  Criteria, 
and  to  explore  how  specific 
architectures  (e.g.,  stack, 
descriptor,  capabilities) 
support  (or  do  not  support)  the 
Criteria.  Liberal  use  should 
be  made  of  case  studies;  the 
idea  is  to  use  real  systems  to 
illustrate  the  points  under 
consideration. 

a.  Basics:  This  section 
will  introduce  the  student  to 
fundamental  concepts, 


d.  Implementation  of 
Protection  Mechanisms:  Here  we 
discuss  the  implementation 
issues  of  protection 
mechanisms.  The  relationship 
between  protection  mechanisms 
and  the  addressing  and  virtual 
memory  mechanisms  will  be 
discussed.  The  impact  of 
various  implementation  choices 
(e.g.,  multiprocessors, 
pipelining,  caches,  address 
translation  buffers,  and  I/O 
architectures)  will  be 
examined.  Explore  trade-offs 
between  hardware  and  software 
implementation. 

e.  Case  Studies: 
Specific  architectures  are 
studied  in  the  light  of 
protection  requirements  and, 
specifically,  the  above 
material.  The  pros  and  cons  of 
each  architecture  are 
discussed.  Ferfox  nee  asp3cts 
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may  be  brought  in  here. 
Candidate  architecture's  to  be 
studied  include: 

-  MULTICS 

-  SCOMP 

-  INTEL  432 

-  BURROUGHS  6500 

-  IBM  370 


TOPIC:  14.  The  Criteria 

^Technical  Version) 

TIME  FOR  STUDF.NT  TO  COMPLETE : 

20  hours 

SUMMARY  OF  MODULE: 

The  purpose  of  this  module 
is  to  acquaint  new  employees  in 
technical  fields  with  the 
purpose,  thrust,  and  structure 
of  the  Criteria,  and  to  present 
the  justification  for  its 
essential  elements  and 
characteristics.  Although  the 
material  will  go  into 
considerable  depth  on  the 
details  of  the  Criteria 
requirements,  it  is  not 
intended  sc  "the  last  word"  cn 
Criteria  tutorials;  it  will 
leave  sufficient  room  for 
further  study  into  the  Criteria 
itself,  as  well  as  related 
areas.  The  student  should  be 
left  with  an  understanding  of 
the  scope  of  the  Criteria,  the 
fundamental  issues  with  which 
it  deals,  the  ways  in  which  it 
deals  with  them,  and  the 
utility  of  the  Criteria.  The 
module  should  provide  the  basis 
for  studying  the  Criteria  in 
greater  depth,  and  in  fact  will 
provide  the  student  the  base 
upon  which  the  final  module 
(''Evaluation  Theory  and 
Practice")  builds  to  develop  a 
much  deeper  appreciation  of  the 
implications  of  the  various 
criteria  requirements.  This 
module  will  also  discuss  the 
role  of  the  Criteria  as  an 
instrument  of  Center  policy. 

a.  Purpose  of  the 
Criteria:  This  section  should 
set  the  stage  by  demonstrating 
the  need  for  a  common  knowledge 
base  from  which  requirements 
can  be  stated  in  a  consistent 
manner.  The  primary  purposes 
of  the  Criteria  to  be  discussed 
will  be: 

-  articulate  fundamental 
issues,  requirements.  It 
should  be  noted  here  that  the 
Criteria  is  presented  in  terms 
of  requirements,  and  does  not 


mandate  implementation;  it 
purposely  leaves  room  for  the 
vendor  to  make  implementation 
choices. 

-  provide  the  basis 
for  an  objective  and  consistent 
metric  of  "security  goodness." 

This  section  will  also  discuss 
the  difference  between  internal 
controls  and  external  controls 
(e.g..  procedures,  physical 
security,  personnel  security) , 
making  it  clear  to  the  student 
that  the  Criteria,  focuses  only 
upon  internal  control 
mechanisms , 

b.  Derivation  From 
Policy:  Discuss  the 
philosophical  underpinnings  of 
the  Criteria,  show  that  it  is 
not  merely  an  arbitrary 
collection  of  good  ideas  but 
rather  it  is  derived  form  basic 
national  policy  requirem'  .its 
and  well  understood  security 
and  scientific  principles. 

Show  how  the  "control 
objectives"  are  derived.  At 
this  point  several  fundamental 
concepts  will  be  introduced  and 
studied  in  some  detail,  such  as 
MAC  and  the  lattice  model,  DAC 
(need-to-know  mechanisms) , 
individual  accountability,  and 
labeling. 

c.  Structure  of  the 
Criteria:  Start  off  with  the 
basic  elements  cf  the  Criteria, 
tying  them  back  to  the  control 
objectives,  and  distinguish 
between  features/mechanism  and 
assurance  elements.  The 
structure  should  be  presented 
in  overview  (i.e.,  D  to  A) 
first.  This  will  give  a  global 
perspective  before  delving  into 
detail,  and  allow  a  chance  for 
presenting  the  justification 
for  choosing  a  linear  (vice 
multi-dimension)  rating 
scheme.  Next,  each  Division 
and  Class  will  be  studied  in 
some  more  detail,  touching  only 
upon  the  main  elements  of  each 
division  and  class.  What  is 
important  here  is  to  discuss 
the  essential  characteristics 
of  each  class,  and  to  show  how 
the  Criteria  progresses  from  an 
emphasis  on  mechanism,  at  the 
lower  levels,  to  an  emphasis  on 
assurance  at  the  higher  levels. 

~  Optional  -  discuss 
the  question  of  "beyond  Al"; 
prognostications,  can  be  used 
to  show  how  the  basic 
technological  and  policy 


thrusts  of  the  Criteria  can  be 
extended,  as  well  as  to  show 
the  Criteria  is  limited  by  the 
state-of-technology  and  at  the 
same  time  provides  the  base 
from  which  technical  direction 
can  be  mapped. 

d-  Related  Topics:  Prior 
to  getting  into  the  fine-grain 
detail  of  each  class  of  the 
Criteria,  some  attention  should 
be  given  to  aspects  of  the 
Criteria  that  are  not  apparent 
from  a  superficial  reading.  In 
particular,  the  topics  to  be 
covered  will  include: 

-  What  is  not  included 
and  why?  denial  of  service, 
reliability,  and  integrity 

-  Rating  scale;  examine 
the  choices  of  one-dimensional 
rating  vs.  a  multi-dimensional 
rating.  What  considerations 
led  us  to  the  choice  we  made, 

-  Relation  to  policy/ 
strategy.  Here  we  will  note 
the  Center  position  that  we 
will  diwava  specify  AOP  system 
requirements  in  terms  of 
Criteria  ratings  (vice  using 
the  Criteria  in  a 
"eut-and-paste"  mode) .  This 
position  will  be  shown  to  be 
consistent  with  the  Center's 
mission  to  make  improved 
products  available  in  the 
marketplace.  It  should  also  be 
shown  to  be  supportable  on  the 
technical  grounds,  that  each 
Criteria  class  is  essentially 
defined  by  its  characteristic 
assurance  elements  (i.e.,  a  B2 
is  a  B2  regardless  of  how  much 
chrome  trim  is  added  or  left 
off) . 


TOPIC:  15.  Theoretical 

Foundations 

TIME  FOR  STUDENT  TO  COMPLETE: 

60  hours  (2  hours  daily  for  6 
weeks) 

SUMMARY  OF  MODULE: 

1.  In  any  security 
evaluation  it  seems  reasonable 
to  begin  by  establishing  the 
security  policy  which  guided 
the  designers  of  the  entity. 

New  technical  colleagues  need 
to  be  acquainted  with  the 
concept  of  the  security  policy 
followed  by  the  various  methods 
by  which  it  has  been 
expressed.  This  leads, 
naturally,  to  the  notion  of  the 


model  as  the  tool  for 
describing  in  precise  language 
the  elements  of  the  security 
policy.  In  order  to  make  a 
meaning  presentation  of  the 
models  it  is  necessary  that  the 
students  have  a  minimal  set  of 
logical  and  mathematical 
notions  at  hand.  For  example, 
they  need  to  know  a  few  notions 
in  set  theory  and  modern 
algebra  (partially  ordered  sets 
and  lattices.)  Consequently,  a 
minimal  presentation  would 
proceed  along  the  following 
lines: 

a.  A  heuristic 
exposition  on  the  notion  of 
security  policy  with  emphasis 
on  defining  security  in  the 
context  of  a  computer  system. 

b.  Basic  notion  of  a 
model  as  a  device  for  defining 
precisely  informally  expressed 

concepts .  ^ ,  , 

c.  Basic  mathematical 
concepts  needed  to  understand 
existing  models  for  secure 
computer  systems.  (If  erne 
objects  to  the  use  of  the  word 
"mathematical,"  it  can  be 
replaced  with  "logical.") 

d.  Basic  notions  of 
access  control .  A  good  survey 
is  found  in  Chapter  4  of 
Denning’s  book.  (It  is  not 
intended  that  the  entire 
chapter  be  covered.) 

2.  When  topics  a.,  b.,  c., 
am,  d.  above  have  been  covered, 
the  studentB  are  ready  to  look 
at  the  model b  themselves.  One 
would  then  proceed  to  present: 

a.  Bell  LaPadula  Model 

b.  Information  Flow  Model 

c.  Non-Interference  Model 

d.  Multi-level  objects  (NRL 
KKS  model;  SYTEK  model) 

3.  it  would  be  helpful,  if 
time  permits,  to  give  examples 
of  existing  systems,  or  those 
in  the  design  process,  which 
incorporate  the  models 
described  in  2.,  or  variations 
thereof . 


TOPIC:  16.  Model 

Interpretations 

TIME  FOR  STUDEHT  TO  COMPLETE: 
16  hours 

SUMMARY  OF  MODULE: 

The  purpose  of  this  module 
ie  to  demonstrate  how  the 
formal  policy  model  and  the 
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reference  monitor  concept  is 
actually  embodied  in  lower 
levels  of  abstraction  (i.e., 
implementation  detail) .  The 
main  thrust  will  be  to  show  how 
step-wise  decomposition  (i.e., 
top-down  design,  development) 
of  the  design  provides  the 
basis  for  the  convincing 
argument  that  the  ultimate 
hardware/software  system  in 
fact  enforces  the  rules  of  the 
policy  model,  end  also  provides 
the  necessary  reference  monitor 
qualities  (i.e., 
seif-protecting,  always 
necessary  to  be  invoked,  small 
enough  to  be  analyzed) .  The 
detailed  module  would  proceed 
as  follows: 

a.  Interpretation  of  the 
model:  Note  the  intellectual 
gap  between  the  different 
levels  of  abstraction 
represented  by  the  formal 
policy  model  and  the  FTLS 
(which  begins  to  include 
significant  implementation 
detail) .  Show  how  that 
intellectual  gap  is  addressed 
through  the  arguments  that  map 
the  state  transition  rules  of 
the  formal  policy  model  to 
functions  of  the  particular 
architecture  (e.g., 
descriptor-based,  stack)  to  be 
implemented.  Case  studies 
which  can  be  used  to  support 
this  section  include  the 
"Unified  Exposition  and  Multics 
Interpretation"  (Bell  and 
LaPadula) ,  Scomp 
Interpretation,  and  Multics 
Interpretation  (Kultics  B2 
evaluation) . 

b.  Formal  Top-Level 
Specifications  (FTLS) : 

Introduce  the  basic  principles 
of  formal,  top-level 
specifications  and 

proof- of-correctness  (or 
verification)  techniques. 

Discuss  the  correct  level  of 
abstraction  of  the  FTLS, 
principles  of  FTLS  design,  what 
defines  the  user/TCB 
interface.  Introduce  the 
concept  of  "trusted  subjects"; 
what  constitutes  "trustedness, " 
what  is  the  role  of  a  trusted 
subject  (i.e,,  why  is  this 
construct  needed?)  Explore  the 
relation  of  the  FTLS  to  the 
Reference  Monitor  Concept; 
which  aspects  of  a  reference 
monitor  are  addressed  by  the 
FTLS,  which  are  not.  Explore 
the  distinction  between 
functional  correctness  and 
proper  security  behavior,  and 


that  the  verification 
technology  addresses  the  latter 
issue. 

Optional  -  Discuss 
covert  channels;  what  are  the 
issues,  where  do  they  come 
from,  what  are  the  design 
considerations  if  they  are  to 
be  eliminated? 

c.  Spec-to-Code 
Mapping:  How  the  FTLS  aro 
carried  into  lower  levels  of 
implementation  detail  and, 
eventually,  into  source  and 
object  code.  Presented  as  the 
continuation  of  the  argument 
that  the  rules  of  the  formal 
policy  model  are  enforced  at 
each  level  of  design,  as  more 
and  ,.,ore  detail  is  introduced. 
Discuss  this  set  of  steps  as  a 
consequence  of  the  limits  of 
the  state-of-technology  in 
verification  (i.e.,  will  not  be 
necessary  at  such  time  as 
verification  of  source/object 
code  is  a  reality) .  Demonstrate 
the  necessity  for  showing  that 
the  following  conditions  are 
both  true; 

-  all  the  code  that 
appears  in  the  TCB  is  directly 
derivable  from  the  FTLS;  no 
additional  functionality  is 
introduced.  All  that  is  added 
is  implementation  detail. 

-  implementation  detail 
which  is  not.  described  at  the 
FTLS  level  represents  only  non¬ 
user-visible  functionality; 
represents  detail  which  js  not 
at  the  TCB  interface. 

Useful  case  study  for  this 
section  is  the  SCOMP 
spec-to-code  mapping,  preceded 
by  a  reading  of  the  MITRE  paper 
on  this  subject  (Benzel) . 


TOPIC:  17.  Correctness 

TIME  FOR  STUDENT  TO  COMPLETE: 

60  hours  (2  hours  daily  for  6 
weeks) 

SUMMARY  OF  MODULE: 

I .  INTRODUCTION 

A,  Background  Knowledge 

1.  Formal  logic 

2 .  Set  theory 

3.  Modeling 

a.  notion  of  using  precise 
language 

b.  exposure  to  expressing 
abstract  concepts  formally 

B.  Basics  in  a  Nutshell 
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1.  What  is  formal 
specif  ioat.  ion? 

2.  Hliat  is  verification? 

3 .  What  good  is  it?  Why 
use  j-t"? 

4.  Role  of  verification  in 
developing  secure  systems. 

XX.  theory 

A.  Read  and  Discuss 
Seminal  Papers 

1.  Floyd's  "Assigning 
Meaning  to  Programs" 

2.  Hoare*  &  “An  Axiomatic 
Basis  for  Computer  Programming" 

3.  Hoare's  "Procedure  and 

Parameters:  An  Axiomatic 

Approach" 

B.  Special  Topics 

1.  information  flow  tools 

a.  recommend  some  of 
John  Rushby's  papers  out  of  SRI 
explaining  the  theory  and 
implementation  of  the 
tools . 

b.  advantages 

c.  restriction  & 
limitations  of  the  approach 

III.  THE  REAL  WORLD 

A.  Gypsy  as  a  Reflection 
of  Floyd/Hoare  Theory 

1,  Brief  description  of 

Gypsy 

2.  How  it's  used 

a.  read  and  discuss 
"Model  and  Design  Proofs  in 
Gypsy:  An  Example  Using  Bell 

and  LaPadula." 

fc>.  possibly  read  anu 
discuss  section  of  "Using  the 
Gypsy  Methodology."  It  depends 
on  the  time  available. 

B.  Applications 

1.  The  EPI  (Encrypted 
packet  Interface)  work  done  at 
Texas.  Recommend  reading 
"Formal  Verification  of  a 
Communications  Processor" 

2.  possibly  read  arid 
discuss  the  paper  in  the 
Scientific  Honeyweller  of  July 
1985  entitled  "Proving  a 
Computer  System  Secure." 

C.  How  to  Evaluate 

1.  Analyze  and 

understand  the  approach  taken. 
Read  and  discuss  "Structuring  a 
System  for  A1  Certification." 
Also  read  and  discuss  Platek's 
paper  on  problems  with  Feiertag 
tool  and  HDM  to  see  the  dangers 
of  placing  too  much  confidence 
in  a  set  of  tools  simply 
because  they  are  on  a  computer. 

2.  Ask  "What's  being 
proved?" 

3.  Ask  "What's  being 


assumed?" 


TOPIC:  18.  Evaluation  Theory 

and  Practice:  Putting  the 
Criteria  to  Use: 

TIME  FOR  STUDENT  TO  COMPLETE: 

40  hours 

SUMMARY  OF  MODULE: 

The  purpose  of  this  module 
is  to  give  the  student  a  full 
appreciation  of  the  Criteria 
and  its  implications.  it  will 
give  the  student  both 
vocabulary  and  true 
understanding  of  the  scientific 
principles  underlying  the 
Criteria,  which  will  allow  him 
to  be  able  to  present/discuss 
the  Criteria  from  a  firm 
technical  base.  It  will  use 
the  Criteria  as  a  central  focus 
in  order  to  consolidate  all  the 
preceding  technical  material. 
The  approach  will  be  to  study 
each  major  class  of  products 
(i.e.,  Cl  -  Bl,  B2,  B3  -  Al) 
with  a  view  to  how  the  concepts 
of  modeling  and  assurance  are 
embodied  at  each  level,  and 
what  the  architectural 
implications  are  on  each 
level.  The  presentation  should 
be  in  the  context  of  choosing 
logical  building  blocks  for 
converting  high-level  models  of 
access  control  and  policy  into 
working  systems  which  enforce 
the  necessary  constraints;  how 
to  progress  from  abstract 
design  to  end  product  in  such  a 
way  that  convincing  arguments 
can  be  made  for  the  correct 
security  behavior  of  the  end 
product . 

a.  Cl  Through  Bl:  The 
approach  here,  as  it  will  be 
for  each  of  these  sections  is 
basically:  "what  is  required 

to  build  one;  what  does  it  mean 
to  satisfy  the  requirements?" 
The  issues  to  be  discussed  will 
be: 

What  are  the  architecture 
issues?  Basically,  what  are 
"credible  controls  capable  of 
enforcing  access 
limitations..."  (Cl);  and  what 
are  the  architectural 
implications?  What  are  the 
implications  of  the  requirement 
that  the  "TCB, . .maintain  a 
domain  for  its  own  execution 
that  protects  it..."? 

What  are  the  assurance 
issues?  What  counts  for  a 
"security  policy  model"  at 
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these  levels  of  the  Criteria, 
and  what  are  the  "convincing 
arguments"  which  can  be  made 
for  believing  that  the 
resultant  system  in  fact 
provides  the  level  of 
protection  desired? 

What  are  the  implementation 
choices;  what  tradeoffs  can  be 
made?  What  specif ic 
architectures  provide  the 
qualities  desired? 

b.  B2:  Primarily  the  same 
discussions  as  above.  A  major 
discussion  should  revolve 
around  the  question  "how  are 
the  B2  requirements,  and  thus 
the  resulting  architecture 
fundamentally  different  from  an 
architecture  which  satisfies 
the  C.l-Bl  requirements;  why, 
and  how,  is  a  B1  architecture 
not  adequate  for  B2?" 

C.  B3  to  Als  Same 
,,  proach  as  above  (details  to 
be  worked  out  by  course 
designer) . 

a.  Lab:  Perform  a  sample 
evaluation;  students  will  show 
reasoning  used  to  decide  what 
level  of  Criteria  is  satisfied 
by  the  system  being  studied. 
Teams  rf  2  or  3  students  will 
evaluate  an  appropriate  device 
(real  or  imaginary)  and  produce 
a  wr^ten  report. 
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DEPARTMENT  OF  THE  NAVY  AUTOMATED  DATA  PROCESSING 
SECURITY  PROGRAM  TRAINING 
OPNAVINST  5239. 1A 


Patricia  Grandy 

Navy  Regional  Data  Automation  Center  San  Francisco 
NAS  Alameda,  CA  94501-5007 
COMM:  (415)  869-5300 
AVN :  686-5300 


ABSTRACT 

The  Naval  Data  Automation  Command  (NAVDAC)  is 
an  echelon  II  command  of  the  Chief  of  Naval 
Operations.  It  consists  of  a  headquarters 
staff  located  in  Washington,  D.C.  having 
echelon  III  and  IV  Automated  Data  Processing 
(ADP)  support  activities  known  as  Navy 
Regional  Data  Automation  Centers  (NARDACs) 
and  Navy  Regional  Data  Automation  Facilities 
(NAVDAFs).  NAVDAC  activities  are  found  in 
most  regions  of  the  united  States  where  there 
is  extensive  Navy  activity. 

The  Commander,  Naval  Data  Automation  Command 
( COMNAVDAC )  conducts  training  for  all 
Department  of  the  Navy  (DON)  and  Marine  Corps 
activities  (Shore  and  Afloat)  and  DON 
contractors.  The  DON  ADP  Security  Program  is 
established  by  OPNAVINST  5239. 1A,  an 
instruction  which  consolidates  all  pertinent 
ADP  security  information  on  policies, 
procedures,  and  responsibilities  for 
establishing  and  maintaining  ADP  security 
programs  at  all  levels  within  the  DON. 

In  Implementing  an  activity  ADP  security 
program,  one  of  the  biggest  obstacles  facing 
the  Commanding  Officer  is  developing  a 
command  awareness  of  ADP  security.  The  DON 
approach  to  a  problem  of  such  magnitude  as 
ADP  security,  is  to  analyze  the  problem  and 
find  solutions  through  Risk  Assessments.  A 
four  day  "Introduction  to  the  DON  ADP 
Program"  Course  provides  an  awareness  of  the 
ADP  security  problem  and  the  need  for  a  Navy 
ADP  Security  Program.  The  course  attendees 
are  middle  management  (GS-9  and  above,  E-7 
and  above)  assigned  as  ADP  security  Officers, 
ADP  System  Security  Officers,  Network 
Security  Officers,  Terminal  Area  Security 
Officers  or  others  with  an  interest  in  ADP 
security.  Class  size  is  maximum  thirty-six 
and  quotas  are  limited  to  two  attendees  from 
a  command  to  ensure  ari  equitable  distribution 
of  experience.  The  course  schedule  combines 
lecture,  outside  reading,  and  workshops  with 
a  modular  workbook  covering  twenty-five 
areas.  The  course  includes  a  challenging  case 
study  to  present  the  two  DON  Risk  Assessment 
Methodologies.  Method  I  instruction  involves 
conducting  workshops  to  systematically  study 
assets,  their  weaknesses  and  strengths,  and 
possible  threats;  determining  the  probability 
of  a  successful  attack  occurring  and  the 
dollar  value  of  its  impact;  and  conducting  a 
cost/benefit  analysis  of  implementing  add¬ 
itional  countermeasures  to  achieve  an  optimum 
level  of  security.  Method  II  is  an 
abbreviated  methodology  for  Risk  Assessment. 


This  approach  is  suitable  for  less  complex 
configurations  and/or  microcomputers. 

NAVDAC,  through  the  NARDACs  and  NAVDAFs 
located  in  San  Francisco,  Washington,  D.C., 
Jacksonville,  Newport,  and  Pearl  Harbor, 
conducts  more  than  fifty  ADP  Security  classes 
annually,  at  locations  all  around  the  world. 


DON  ADP  SECURITY  PROGRAM  TRAINING 
OPNAVINST  5239. 1A 

The  purpose  of  the  DON  ADP  Security  Program 
Training  is  to  provide  ADP  Security  Staff 
personnel  with  an  overview  of  the  Navy  ADP 
Program,  which  includes  defining  the  scope  of 
the  Navy  ADP  Program,  providing  an  awareness 
of  tne  ADP  security  proDlem,  and  emphasizing 
the  need  for  a  working  activity  ADP  Security 
Program. 


OPNAVINST  5239. 1A,  the  ADP  Security  Manual, 
is  a  directive.  A  directive  requires 
compliance.  What  is  "ADP  Security"  all  about? 
In  a  few  words,  it  is  the  means  for 
protecting  our  investment  in  automated  data 
processing.  In  our  ADP  "portfolio",  we  have 
invested  many  dollars  and  much  time  in  the 
five  asset  areas  defined  in  the  DON  ADP 
Security  Program.  They  are; 


I.  HARDWARE 

I I .  DATA 

III.  HUMAN  RESOURCES 

IV.  SOFTWARE 

V.  COMMUNICATIONS 


DON  ADP  SECURITY  (FIVE  AREAS) 
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The  DON  AIM’  Security  Course  consists  ol  the 
following  modules  presented  in  a  combination 
Ot  lecture,  conference,  and  workshop 
sess  i  ons . 

DON  A  OP  SIX  OKI TV  POLICY 

The  objective  of  this  session  is  to  inform 
the  students  that  the  current  Navy  ADP 
Security  Policy  is  a  composite  of  existing 
Department  of  Defense  (DOD)  and  Navy  ADP 
security  requirements.  The  discussion 
includes  each  specific  element  of  DOD  and 
Navy  policy  upon  which  the  Navy's  ADP 
Security  Program  is  presently  based. 

ADP  SECURITY  PROGRAM  RESPONS I B I LI Tl ES 
This  session  helps  the  students  to  understand 
the  distribution  of  pol  icy-mak  i  nij  ,  program 
management,  operating  and  program  review 
responsibilities  of  National  Agencies,  and 
Navy  Offices  involved  in  the  DON  ADP  Security 
Program.  The  students  are  instructed  on  the 
individual  responsibilities  of  the  Designated 
Approving  Authority  (DAA),  the  Commanding 
Officer  and  the  ADP  Security  Staff  members 
and  will  be  able  to  explain  how  these 
individuals  interact  to  support  an  ADP 
Security  Program  at  the  Navy  activity  level. 
The  DON  ADP  Security  Staff  consists  of  an  ADP 
Security  (ADPSO),  a  Network  Security  Officer 
(NSO),  ADP  System  Security  Officers  (ADPSSO), 
Terminal  Area  Security  Officers,  an  Office 
Information  System  Officer,  the  activity 
Security  Manager  and  Security  Officer,  as 
required.  Additional  security  personnel,  such 
as  Top  Secret  Control  Officer  and  CMS 
Custodian,  are  discussed  as  they  interface 
with  the  ADP  Security  Staff. 

ACCREDITATION  OF  NAVY  ADP  ACTIVITIES  AND 
NETWORKS 

The  objective  of  this  session  is  to  instruct 
the  student  on  the  accreditation  concept  and 
provide  guidance  on  how  to  apply  these 
concepts  to  their  own  activity.  A  Statement 
of  Accreditation  is  the  DAA's  formal 
declaration  that  an  appropriate  security 
progiam  has  been  implemented  for  an 
activity's  systems  or  networks  consistent 
with  Levels  I,  11,  and  III  data  protection 
requ i romonts. 

SECURITY  OF  NAVY  OFFICE  INFORMATION  SYSTEMS 
(OIS) 

The  objective  of  this  session  is  to  apply  the 
knowledge  of  DON  data  levels  to  determine  how 
OIS  are  be  secured  and  which  accreditation 
elements  apply  to  the  security  of  these 
systems  in  their  own  activities. 

MICROCOMPUTER  SECURITY 

This  session  discusses  security  requirements 
for  Personal  Computers  (PCs),  as  well  as, 
suggestions  for  developing  an  activity 
policy  on  (1)  privately-owned  PCs  accessing 
DON  data  from  non -government  controlled 
workspaces  (e.g.,  home);  (2)  the  use  of 
privately-owned  software  and  data  for 
government  business;  and  (3)  privately-owned 
PCs,  software  and  data  brought  into 
government  controlled  workspaces.  This 
session  emphasizes  developing  an  activity 
policy  on  adherence  to  software  licensing 
agreements  for  copyrighted  software  packages. 


AFLOAT  SECURITY 

Shipboard  computer  systems  provide  unique 
considerations  with  respect  to  ADP  Security. 
This  session  discusses  physical  security 
requirements  for  afloat  unite  wtien  underway, 
in  foreign  ports,  and  in  drydock  or  a 
shipyard,  TEMPEST  certification  (policy  and 
guidance  from  Type  Commanders),  and  shipboard 
ADP  Security  certification  for  particular 
computer  systems,  such  as,  ttie  Shipboard  Non- 
Tactical  ADP  Program  II  (SNAP  11). 

THE  PRIVACY  ACT 

This  session  is  designed  to  make  the  students 
aware  of  the  significance  and  impact  of 
Public  Law  93-579  (The  Privacy  Act  ot  1974). 
The  st  udents  are  instructed  in  bow  to  apply 
Conditions  for  Disclosure  of  information, 
identity  releasable  information,  and  explain 
agency  requirements. 

MINIMUM  ADP  SECURITY  REQUIREMENTS 
This  session  teaches  the  students  to  relate 
Navy  ADP  security  requirements  to  their  own 
activities,  recognizing  any  deficiencies  in 
existing  ADP  security  programs.  Minimum 
mandatory  requirements  include  environmental 
controls  (temperature,  humidity,  lighting, 
electrical  power,  cleanliness,  water  damage, 
fire  safety,  smoke  detection,  etc.),  physical 
security  (facility,  remote  terminal  areas, 
disconnect  procedures,  control  zones,  etc.), 
communications  security,  emanations  security, 
hardwa  .‘/software  security,  and  contingency 
planning . 

EMANATIONS  SECURITY 

Emanations  security  discusses  measures  to 
control  compromising  emanations  (BKSEC), 
which  arc  required  under  the  provisions  of 
DOD  S-5200.19,  Control  of  Compromising 
Emanations  (U)  and  supplemented  by  OPNAVINST 
C5510.93D.  Students  are  made  aware  of  the 
risks  associated  with  using  equipment  which 
produces  compromising  emanations,  to  enable 
them  to  recognize  the  various  countermeasures 
to  be  implemented  at  their  ADP  facility.  The 
session  discusses  how  to  initiate  requests 
for  TEMPEST  Vulnerability  Assessments  ( TVARs ) 
for  all  ADP  and  OIS  systems  for  processing 
Level  1  data  and  the  necessary  procedures  to 
follow  to  obtain  TEMPEST  Accreditation- 

SECURITY  OF  ADP  MEDIA 

This  session  is  designed  tc  enable  the 
students  to  apply  the  requirements  of  both 
the  Navy  information  and  ADP  security 
programs  to  marking,  accounting  for,  and 
handling  Level  1  (  lassified)  and  Level  II 
data  recorded  on  ADP  media. 

ADP  SECURITY  SURVEYS  AND  CHECKLISTS 
This  session  provides  the  students  an 

instruction  in  the  use  of  a  standard  ADP 
security  survey  format  to  account  for  the 
status  of  ongoing  ADP  security  programs  in 
Navy  computer  systems  and  networl.s. 

RISK  MANAGEMENT  CONCEPTS 

This  session  is  designed  to  provide  tne 
student  a  working  knowledge  of  the  role  of 
Risk  Management  as  an  Accreditation  Process 
and  will  be  able  to  relate  the  Risk 
Assessment,  Security  Test  and  Evaluation,  and 
Contingency  Planning  sub-processes  to  an 
Activity-level  Risk  Management  Program. 
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ACTIVITY  ADP  SECURITY  PLAN  (AADPSP)  AND 
ACTIVITY  ACCREDITATION  SCHEDULE  (AAS) 

The  students  are  Instructed  in  how  to  develop 
a  plan  for  establishing  a  cohesive  ADP 
Security  Program  within  their  activities, 
utilizing  the  AADPSP  requirements.  The  plan 
def ines : 

X.  Scope  of  the  Activity  ADP  Security 
program 

2.  commanding  Officer's  Policy  Statement 

3.  aDP  Organization  and  Responsibilities 

4.  objectives  of  the  Activity  ADP 

Security  Program 

5.  Description  of  the  Current  ADP 

Security  Environment 

6.  ADp  Security  Training 

7.  Audit/Internal  Review 

8.  APP  Security  in  Life  Cycle  Management 
S.  APP  Security  in  Configuration  Control 

10.  The  Activity  Accreditation  Schedule 
(AAS) 

The  AAS  provides  a  Plan  of  Action  and 

Milestones  (POAS.M)  for  the  Accreditation 
progress  of  the  Activity. 

RISK  ASSESSMENT  (METHOD  I) 

Risk  Assessment  (Method  I)  instructs  the 
students  to  be  able  to  determine  the 

circumstances  in  which  Method  I  Risk 
Assessments  must  be  performed,  understand  the 
steps  involved  in  this  method  and  bo  prepared 
to  organize  and  manage  Risk  Assessment 
studies  in  their  own  activities. 

CASE  STUDY  PROBLEM 

Within  this  session  the  students  combine 
information  obtained  during  an  ADP  security 
survey  with  additional  information  provided 
about  the  scope  of  operations  at  a  fictitious 
ADP  activity.  The  members  of  the  class  are 
divided  into  Risk  Assessment  Teams  and 
provided  information  to  plan  and  conduct  a 
Method  i  Risk  Assessment.  The  workshop 

presentations  are  critiqued  by  the  other 
teams  and  class  solutions  are  discussed. 


and  the  threat/vulnorability  evaluations  to 
calculate  an  Annual  Loss  Expectancy  (ALE)  for 
the  Case  Study  ADP  activity.  The  AL.E 
determination  process  is  based  on  the  FIPS 
PUB  65  ALE  formula: 


LOSS 


IMPACT  X  FREOUENCY  OF  OCCURRENCE 
YEARS 


COUNTERMEASURES  SELECTION  WORKSHOP 
The  members  of  the  Risk  Assessment  Teams 
select  and  prioritize  cost-effective 

countermeasures  to  reduce  the  ALE  of  the 
Case  Study  ADP  activity. 

RISK  ASSESSMENT  (METHOD  II) 

This  session  instructs  the  students  to 
perform  an  abbreviated  Risk  Assessment  using 
Method  II  techniques.  Method  II  includes  the 
processes  of  asset  identification  and 
valuation,  threat  and  vulnerability 

evaluation,  ALE  computation,  and  evaluation 
and  selection  of  additional  countermeasures. 

This  methodology  is  appropriate  for  less 
complex  ADP  systems  and  most  microcomputer 
systems. 

SECURITY  TEST  AND  EVALUATION  (ST&E) 

The  objective  of  this  session  is  to  provide 
the  students  an  understanding  ol  Security 
Test  and  Evaluation  as  a  component  of  Risk 
Management  programs  and  as  a  part  of  the 
accreditation  process.  The  students  will  be 
able  to  plan  or  conduct  an  ST&E  within  their 
uW ii  activities. 

contingency  planning 

This  session  is  designed  to  provide  a  general 
knowledge  of  the  Contingency  Planning 
process.  This  session  enables  the  student  to 
understand  how  Contingency  Plans  contribute 
to  Risk  Management  programs  and  when  they  are 
required  for  the  accreditation  of  Navy  ADP 
activities  and  networks. 


ASSETS  EVALUATION  WORKSHOP 

Each  team  performs  asset  valuation  for  one 
category  cf  assets  typical  of  a  Navy  ADP 
activity  (such  as  data,  hardware,  software, 
telecommunications,  personnel,  administrative 
procedures).  The  workshop  includes  asset 
identification,  asset  grouping,  asset 
valuation  and  determining  risk  assessment 
impact  values  in  the  areas  of  Modification, 
Destruction,  Disclosure,  and  Denial  of 
Service . 

THREAT  AND  VULNERABILITIES  EVALUATION 
WORKSHOP 

The  students  conduct  threat  evaluations  for  a 
related  set  of  threats  typical  of  those 
common  to  Navy  ADP  activities.  The  workshop 
includes  a  description  of  the  threat, 
justification  of  the  vulnerabilities  that 
exist,  identification  of  the  existing 
countermeasures,  and  estimation  of  frequency 
of  successful  attack  for  each  impact  area  of 
Modification,  Destruction,  Disclosure,  and 
Denial  of  Service. 

ALE  DETERMINATION  WORKSHOP 

The  members  of  the  Risk  Assessment  Teams 
utilize  the  results  of  the  asset  valuations 


AUDIT  AND  COMPLIANCE 

The  objective  for  this  session  is  to  instruct 
the  students  concerning  the  role  of  Navy 
auditors  and  IG  teams  in  reviewing  the 
security  programs  of  Navy  ADP  and  OIS 
activities. 

ACTIVITY  ADP  SECURITY  TRAINING 
This  session  is  designed  for  the  students  to 
understand  the  activity  level  training 
requirements  imposed  by  the  DON  ADP  Security 
Proqram  and  information  concerning  those 
al  rnatives  available  for  meeting  the 
requirements . 

CONTRACTING  AND  REQUESTS  FOR  PROPOSALS 
This  lesson  enables  the  students  to  review 
the  requirements  of  *-he  contracting  needs 
with  COMNAVDAC  and  understand  the  role  of  the 
ADP  security  staff  in  their  activity  con¬ 
tracting  process. 

NATIONAL  COMPUTER  SECURITY  CENTER  ( NCSC ) 

This  session  will  provide  guidelines  for  the 
student  to  review  the  primary  and  secondary 
mission  of  NCSC,  understand  the  concept  of 
the  Trusted  Computer  System,  and  describe  how 
the  Center  can  be  tasked  by  DON  activities. 
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COURSE  EVALUATION  AND  QUIZ 

The  students  complete  a  quiz  covering  the 
major  issues  piosented  during  the  course.  In 
addition,  students  are  provided  with  an 
opportunity  to  evaluate  the  quality  end 
usefulness  of  course  eontents. 


SUMMARY 

What  does  OPNAVINST  S239.1A  require?  Your 
local  NAVDAC  activity  will  teach  you  what  you 
need  to  know.  Come  to  one  of  our  classes,  or 
arrange  for  our  class  a'-  your  site,  to  learn 
iiow  to  : 


-  Conduct  Risk  Assessments 

-  Conduct  a  Security  Test  and  Evaluation 
(STUB) 

-  Prepare  and  Test  Contingency  Plans 

-  Prepare  an  Activity  ADP  Security  Plan 
and  Activity  Accrod itati on  Schedule 
(AADPSP/AAS ) 

-  Prepare  a  Statement  of  Accreditation 

-  Obtain  Contractor  Assistance  tor  ADP 
Security  Compliance 

-  Obtain  Assistance  in  All  ot  the  Above 
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SOCIAL  ASPECTS  OF  COMPUTER  SECURITY 


Dorothy  E.  IX-nniug,  lVtcr  G.  Neumann,  and  l>onn  U.  Parker 
SRI  international,  333  Havenswood  Avc.,  Menlo  Park,  GA  94025 


Introduction 

The  problem  of  computer  misuse  (intentional  and  acciden¬ 
tal)  has  been  a  growing  concern  as  the  number  of  computers 
and  users  increases,  ind  as  computers  become  an  integral  el¬ 
ement  in  areas  such  as  medicine,  finance,  and  defense.  This 
concern  has  led  i*-  advances  in  computer  security  technol¬ 
ogy,  and  to  the  Department  of  Defense  Trusted  Computer 
System  Evaluation  Criteria[l],  which  give9  criteria  for  eval¬ 
uating  the  security  of  computer  systems  in  terms  of  the  poli¬ 
cies  to  be  enforced  and  “-e  assurance  one  can  obtain  in  the 
correct  enforcement  of  those  policies.  The  “Criteria"  re|>- 
resents  a  significant  step  forward  in  the  computer  security 
area. 

The  objective  of  this  paper  is  to  examine  social  aspects 
of  computer  security,  particularly  with  respect  to  some  of 
the  technologies  being  developed.  We  believe  that  the  prob¬ 
lem  of  computer  misuse  must  he  addressed  within  a  broader 
context  that  ineludes  the  people  who  regulate  and  use  the 
system,  and  the  information  resources  that  aie  external  to 
the  system.  Security  policies  and  mechanisms  must  be  eval¬ 
uated  in  terms  of  their  effect  on  privacy  and  productivity, 
and  in  terms  of  the  actual  and  perceived  threats  they  ad¬ 
dress.  If  we  ignore  these  social  aspects,  then  there  is  the 
danger  of  developing  technologies  that  arc  not  cost  effec¬ 
tive,  do  not  address  the  actual  threats,  or  jeopardize  human 
rights. 

In  an  article  on  system  safety,  Leveson  [2]  observes  that 
“Safety  is  a  system  problem,"  and  goes  on  to  show  that 
one  cannot  make  systems  safe  just  by  focusing  on  software 
and  hardware  issues.  Instead,  one  must  examine  the  total 
system  and  its  social  aspects,  including  political,  legal,  and 
ethical  issues. 

The  same  is  true  of  computer  security.  We  must  pay 
greater  attention  to  the  issues  of  user  productivity,  privacy, 
ethics,  acceptance  of  security  measures,  the  nature  of  the 
threats,  and  the  role  of  computer  security  within  the  broader 
context  of  information  security. 

In  the  remainder  of  this  paper,  we  elaborate  on  four 
topics  relating  to  the  social  aspects  of  computer  security: 
security  policy  definition  and  awareness,  user  productivity, 
privacy,  and  the  broad  area  of  information  security.  For  each 
of  these  topics,  we  make  specific  recommendations  aimed  at 
improving  overall  information  security. 


Security  Policy  Definition  and 
Awareness 

In  many  environments,  information  managers  and  workeis 
lack  the  knowledge,  motivation,  and  support  to  apply  ba¬ 
sic  security  controls  and  practices.  This  is  particularly  true 
in  business,  where  there  are  few  written  rules  about  how 
the  computers  may  be  used.  It  is  not  surprising  that  the 
systems  are  misused,  because  the  users  and  their  organiza¬ 
tions  are  not  rlear  what  the  rules  are.  Also,  many  users  arc 
not  consciously  aware  of  how  their  carelessness  ran  delelori- 
ously  affect  other  users  who  are  sharing  the  same  resourees 
(including  computer  networks) 

There  have  been  many  violations  of  data  piivaey  and  in¬ 
tegrity,  with  a  wide  variety  of  motivations  -  personal  gain, 
greed,  curiosity,  harassment,  etc.  Documented  eases  include 
external  system  break-ins;  internal  fraud  and  embezzlement; 
implantation  of  destructive  Trojan  horses,  software  time¬ 
bombs  inserted  for  blackmail,  spoofing,  jamming,  and  so  on. 
Hiding  of  knowledge  about  system  security  vulnerabilities 
often  (e.g.,  by  system  purveyors)  creates  a  head-in-the-sand 
attitude,  ripe  for  underground  dissemination  of  the  vulnera¬ 
bilities  (which  are  usually  known  anyway)  and  abuse.  Open 
disi  ussion  of  such  knowledge  al:  creates  problems,  as  it 
whets  the  appetites  of  would-be  perpetrators. 

The  federal  computer  erime  law  and  it  state  statutes 
define  as  crimes  unauthorized  arts  with,  within,  or  to  com¬ 
puters.  This  makes  it  imperative  for  computer  systems  man¬ 
agers  to  make  clear  what  is  unauthorized,  such  as  personal 
use  of  electronic  mail  and  other  computer  resources.  AH 
employees  should  have  explicit  requirements  to  protect  in¬ 
formation  a-ssets  in  their  job  descriptions  ami  performance 
evaluation  criteria.  Adequate  motivation  to  support  secu¬ 
rity  will  not  he  achieved  uutil  there  are  well-defined  secu¬ 
rity  policies  and  until  security  is  considered  part  of  one’s 
job,  since  security  can  otherwise  be  viewed  as  an  obstacle 
to  productivity. 

In  order  to  assist  organizations  develop  security  policies, 
policy  guidelines  can  be  developed  for  various  types  of  or¬ 
ganizations  and  various  degi.'os  of  risk.  These  guidelines 
could  he  developed  through  industry  and  professional  asso¬ 
ciations,  such  as  the  ACM  External  Activities  Board,  the 
IEEE,  and  the  Data  Processing  Management  Association. 
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The  guidelines  would  suggest  possible  policies  about  what 
is  considered  to  be  acceptable  use  of  an  organization’s  infor¬ 
mation  resources,  including  personal  computers.  The  policy 
guidelines  should  address  the  broad  social  issues  such  as  user 
productivity  and  privacy  rights,  discussing  tradeoffs  as  they 
arise.  Based  on  the  guidelines,  each  organization  would  for¬ 
mulate  its  own  specific  policies  in  accordance  with  the  sen¬ 
sitivity  and  value  of  the  information  (and  other  resources) 
to  he  protected,  and  the  threats,  vulnerabilities,  and  risks. 

When  a  user  is  given  an  account  on  a  system,  or  other 
information-related  responsibility,  the  user  might  be  asked 
to  road  and  sign  the  organization’s  policy  statement.  Mak¬ 
ing  the  security  policy  clear,  together  with  asking  all  users  to 
make  a  commitment  to  the  policy,  could  help  eliminate  much 
computer  misuse  (both  internally  and  externally),  while  at 
the  same  time  helping  the  users  appreciate  the  need  for  se¬ 
curity  and  the  benefits  to  be  gained  by  it,  including  making 
them  of  greater  value  to  their  organizations. 

Policies  for  using  personal  computers  can  be  developed 
for  elementary  and  secondary  schools.  Such  policies  should 
contain  a  clear  statement  that  personal  computers  are  not 
to  be  used  for  unauthorized  entry  into  other  computer  sys¬ 
tems  (when  in  doubt,  ask  for  permission).  This  could  help 
reduce  the  malicious  hacker  problem.  Since  break-ins  are  of¬ 
ten  performed  more  out  of  challenge  than  malicious  intent, 
alternative  challenges  can  be  presented  to  the  students  in 
the  schools.1 

Overall  there  is  a  great  absence  of  pervasive  and  cred¬ 
ible  ethical  principles;  on  the  other  hand,  there  are  many 
incentives  (e  g.,  weak  technology)  tor  violating  such  a  code 
of  ethics,  even  if  it  did  exist.  Nevertheless,  such  a  code 
should  be  established,  widely  taught,  and  thoroughly  prac¬ 
ticed  within  the  context  of  an  overall  security  policy. 

Productivity 

A  main  purpose  of  computers  is  to  aid  the  productivity  of 
people  and  organizations.  Many  users  rescind  negatively 
towards  computer  security,  because  they  view  it  as  interfer¬ 
ing  with  their  productivity.  At  least  two  factors  contribute 
to  this  attitude:  First,  many  users  are  not  consciously  aware 
of  how  security  helps  thorn  with  their  work,  for  example,  by 
protecting  their  files  from  accidental  or  malicious  destruc¬ 
tion,  and  by  allowiug  selective  on-line  access  to  sensitive 
information.  Second,  many  security  mechanisms  are  overly 
complicated  or  tedious  to  use  or  install. 

In  addition,  many  organizations  are  reluctant  to  install 
security  mechanisms  that  degrade  the  performance  of  the 
system  or  otherwise  interfere  with  productivity.  Indeed, 
many  security  mechanisms  should  not  be  installed  for  this 
very  reason,  because  they  arc-  not.  justified  by  a  cost/risk 
trade-off.  Organizations  arc  also  reluctant  to  switch  to  more 
secure  systems  if  th  more  secure  systems  are  not  compat¬ 
ible  with  the  existing  systems  or  provide  less  functional¬ 
ity.  UNIX,  for  example,  has  remained  popular  despite  its 
security  weaknesses,  because  its  functional  properties  con- 

1 A  recent  study  ou  the  antisocial  behavior  of  certain  members  of  the 
computer  community  |3|  concluded  that  rather  different  approaches  to 
education  arc  required:  ”...  the  cost  of  these  educational  environments 
may  he  considerably  less  than  the  losses  being  incurred."  One  particular 
recommendation  was  this:  "Access  to  real  computing  power  should  be 
established  for  interested  users,  both  students  and  their  parents.  Em¬ 
powerment  can  lead  to  increased  lcsponsibllity." 


tribute  to  user  productivity.  Because  of  its  popularity,  sev¬ 
eral  secure  versions  of  UNIX  are  under  development  (e.g., 
sec  [1]).  In  many  environments,  compatibility,  performance, 
and  functionality  take  precedence  over  security  when  up¬ 
grading  to  a  new  system. 

If  our  goal  as  computer  security  professionals  is  to  make 
systems  more  secure,  then  we  must  pay  greater  attention  to 
the-  impact  of  our  policies  and  mechanisms  on  productivity 
In  particular,  we  should  strive  for  policies  and  mechanisms 
that,  within  the  scope  of  threats  they  address,  are  trans¬ 
parent  to  users,  simple  to  install  and  use,  and  offer  positive 
benefits  to  the  user  community.  To  illustrate,  we  will  dis¬ 
cuss  two  broad  classes  of  security  controls:  identification 
and  authentication  of  users,  and  discretionary  and  manda¬ 
tory  access  controls. 

Identification  and  Authentication 

A  variety  ol  different  mechanisms  has  been  developed  to 
identify  and  authenticate  users,  including  passwords,  chal- 
lengo/response  protocols,  biometrics,  keystroke  dynamics, 
access  cards,  and  smart  cards.  These  mechanisms  vary  con¬ 
siderably  both  in  terms  of  the  security  they  provide  and 
their  impact  on  productivity.  For  example,  long  meaning¬ 
less  password)  may  offer  greater  security  than  short,  easy- 
to-remember  ones  (if  the  users  do  not  write  them  down  in 
obvious  locations),  but  are  also  more  annoying  to  users. 
Some  security  experts  have  proposed  using  super-long,  but 
meaningful,  passwords,  but  we  do  not  know  whether  these 
are  preferred  by  users  over  shorter,  nonsense  passwords, 
because  they  require  extra  key  strokes.  Moreover,  simply 
lengthening  passwords  does  not  protect  them  from  possible 
exposure  during  transmission.  Cryptographic-based  rhat- 
lenge/response  protocols ,  such  as  the  J’FX  system  devel¬ 
oped  by  Sytek,  can  protect  against  certain  threats  not  ad¬ 
dressed  by  passwords  alone  (including  the  exposure  threat 
during  transmission),  but  at  the  same  time  lengthen  the 
tune  required  to  login.  Biometrics,  such  as  signature  ver- 
ification,  hand  geometry,  voice  prints,  and  electronic  fin¬ 
gerprints  can  add  significant  security,  but  can  be  expen¬ 
sive  and  generally  require  special  equipment.  Authentica¬ 
tion  through  keystroke  dynamics  is  attractive  in  terms  of 
user  productivity,  because  it  is  totally  passive,  low-cost,  and 
transparent,  requiring  no  action  on  the  part  of  users.  In  ad¬ 
dition,  it  offers  continuous  authentication,  thereby  protect¬ 
ing  a  user’s  session  while  the  user  is  absent  from  the  termi¬ 
nal.  On  the  other  hand,  because  of  its  passivity,  it  might 
raise  privacy  issues  under  certain  circumstances  if  the  users 
are  not  aware  of  its  presence  (we  will  return  to  this  in  the 
next  section).  Smart  cards  also  can  provide  a  high  level  of 
security  without  the  need  for  much  user  interaction  during 
login,  but  again  require  special  equipment. 

In  addition  to  the  various  identification  and  authentica¬ 
tion  mechanisms,  various  strategies  are  applied  when  a  user 
requests  access  to  a  subsystem  or  remote  host.  In  mary  envi¬ 
ronments,  the  user  must  supply  a  separate  password  for  each 
subsystem  or  remote  host.  Because  this  places  an  extra  bur¬ 
den  on  the  user,  these  additional  passwords  are  frequently 
stored  on  the  system,  unencrypted,  where  they  arc  vulnera¬ 
ble  to  exposure.  Mechanisms  that  provide  a  high  degree  of 
security  without  requiring  any  additional  information  from 
the  user  better  support  the  concept  that  computers  are  there 
to  aid  people. 
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Access  Controls 

Discrotionary  and  mandatory  (multilevel)  access  controls 
can  aid  productivity  by  allowing  sensitive  information  that 
serves  the  needs  of  different  users  to  coexist  on  a  single  host 
computer  or  network.  Without  adequate  host  or  network  ac¬ 
cess  controls,  it  is  necessary  both  physically  and  logically  to 
isolate  the  information,  which  interferes  with  a  user’s  ability 
to  access  and  integrate  information.  For  example,  because 
no  commercial  system  supports  a  multilevel-secure  database 
system,  users  who  are  cleared  for  information  having  differ¬ 
ent  access  classes  (e.g.,  different  sensitivity  levels  and/or  dif¬ 
ferent  compartments)  cannot  access  that  data  from  a  com¬ 
mon  database  or  manipulate  it  in  a  single  session. 

Discretionary  access  controls  are  often  complicated,  mak¬ 
ing  it  difficult  to  grant  or  revoke  access  to  an  individual 
user,  and  difficult  to  understand  the  implications  of  doing 
so.  The  former  is  due  in  part  to  inadequate  user  interfaces. 
For  example,  on  some  systems  one  must  remember  obscure 
commands  for  granting  access  and  even  what  bit  patterns 
correspond  to  what  access  modes!  Search-path  strategies 
further  complicate  matters.  The  latter  is  due  in  part  to  the 
inherent  limitations  of  discretionary  controls  [5,G],  and  their 
lack  of  policy  about  information  flow,  including  copies  of 
information.  The  “setuid”  facility  of  UNIX,  for  example, 
attempts  to  provide  a  mechanism  for  enforcing  the  principle 
of  “least  privilege,”  but  has  dire  consequences  if  not  used 
correctly.  Because  ol  the  complications  associated  with  dis¬ 
cretionary  controls,  many  users,  accidentally  or  intention¬ 
ally,  grant  access  to  all  users  rather  than  to  those  with  a 
need  for  access. 

Network  access  controls  are  often  inadequate  and  diffi¬ 
cult  to  analyze.  For  example,  some  network  facilities  have 
all  sorts  of  special  conventions  whereby  a  user  can  remotely 
login  or  copy  files  from  one  machine  to  another  without  giv¬ 
ing  a  password.  However,  there  is  no  clear  security  policy 
or  model  underlying  the  mechanisms,  and  the  result  can 
be  total  confusion  and  misapplication  of  the  functionality. 
Reid  [7]  describes  how  intruders  broke  into  a  network  of 
UNIX  systems  by  exploiting  vulnerabilities  in  system  direc¬ 
tories  and  permission  files.  These  vulnerabilities  often  arose 
from  shortcuts  taken  by  programmers  to  improve  their  own 
productivity,  thus  demonstrating  the  importance  of  provid¬ 
ing  secure  mechanisms  that  do  not  burden  the  users,  and 
the  importance  of  making  users  aware  of  the  consequences 
of  break-ins. 

Several  studies  [8,9,10)  have  shown  the  value  of  multi¬ 
level,  lattice-based  policies  for  controlling  direct  and  indirect 
(via  information  Row)  access  to  information  of  different  sen¬ 
sitivities  —  that  is,  for  enforcing  multilevel  security.  Such 
policies  are  relatively  easy  to  understand,  avoid  the  need 
for  users  to  grant  and  revoke  access,  and  avoid  the  inher¬ 
ent  limitations  of  discretionary  policies.  Moreover,  because 
of  their  simplicity,  it  is  possible  to  build  systems  that  en¬ 
force  multilevel  security  with  a  high  level  of  assurance  (B3 
or  At),  and  such  systems  are  now  becoming  commercially 
available.  These  systems  are  based  on  the  concept  of  a  ref¬ 
erence  monitor  or  security  kernel.  Examples  include  the 
Honeywell  SCOMP  and  the  Gemini  GEMSOS  [11],  Sys¬ 
tems  with  a  lower  level  of  assurance  (B1  or  B2)  could  have 
enormous  practical  value  in  environments  where  the  threat 
is  not  great,  but  the  simplicity  of  multilevel  security  is  de¬ 
sirable. 


Applications  are  under  development  that  cau  exploit  the 
properties  of  a  system  enforcing  multilevel  security.  For  ex¬ 
ample,  under  sponsorship  by  the  U.S.  Air  Force  Rome  Air 
Development  Center  (RADC),  a  team  at  SRI  International 
and  Gemini  Computers  is  developing  a  formal  policy  model 
and  design  for  a  multilevel-secure  database  system,  which  is 
to  bo  implemented  on  top  of  a  reference  monitor  (c.g.,  GEM¬ 
SOS)  in  order  to  provide  A1  assurance  [12,13,14].  The  de¬ 
velopment  of  such  applications  will  enable  users  to  integrate 
sensitive  data  of  different  classifications,  thereby  improving 
user  productivity. 

Although  most  of  the  early  work  on  multilevel  security 
was  aimed  at  protecting  classified  data,  some  was  aimed  at 
protecting  sensitive  data  in  the  public  sector  [10],  including 
proprietary  and  confidential  data.  Lipnei  [15]  has  shown 
how  multilevel  policies  can  be  applied  to  commercial  data, 
and  Cohen  [16]  has  argued  that  such  policies  help  protect 
against  computer  viruses.  Although  we  do  not  claim  that 
multilevel  policies  and  mechanisms  can  replace  discretionary 
ones,  we  believe  that  their  potential  in  the  commercial  sec¬ 
tor  has  largely  been  ignored.  While  some  organizations  in 
the  public  sector  have  made  efforts  to  classify  information, 
few  if  any  have  attempted  clearance  of  their  users.  Both 
classification  and  clearance  must  be  rigorously  and  compre¬ 
hensively  accomplished  in  order  to  obtain  the  full  benefits 
of  multilevel  security. 

While  multilevel  security  can  improve  productivity  by 
allowing  the  integration  of  sensitive  data  having  different 
sensitivity  markings,  if  misused,  it  can  inhibit  productiv¬ 
ity  by  restricting  the  How  of  information,  thereby  interfer¬ 
ing  with  the  needs  for  efficient,  timely,  and  effective  anal¬ 
ysis  of  information.  For  example,  attempting  to  eliminate 
all  covert  channels  in  a  system  improves  security,  but  also 
impairs  communication  and  the  flow  of  information;  simi¬ 
larly,  attempting  to  solve  all  possible  inference  and  aggrega¬ 
tion  problems  improves  security,  but  makes  data  integration 
and  analysis  more  difficult.  When  security  and  productivity 
compete,  the  appropriate  balance  can  be  determined  only  by 
examining  the  particular  application  environment. 

Discretionary  access  controls  are  useful  as  a  means  of 
providing  a  finer  granularity  of  control  in  order  to  enforce 
“nccd-to-know”  constraints  within  the  assigned  classifica¬ 
tions.  However,  because  they  are  inherently  more  compli¬ 
cated  and  weaker  than  mandatory  ones,  they  should  not  be 
relied  upon  to  control  the  flow  of  sensitive  information.  The 
limitations  of  discretionary  controls  are  particularly  evident 
in  databases,  where  access  controls  may  be  at  the  view  level 
for  transaction  level)  so  that  authorization  can  be  value- 
dependent,  context-dependent,  or  history-dependent. 

Other  types  of  controls  are  also  needed  in  order  to  en¬ 
sure  the  consistency  or  integrity  of  data,  and  to  enforce 
other  security  policies.  Our  formal  mode!  of  a  multilevel- 
secure  database  system,  for  example,  supports  database  con¬ 
sistency  through  integrity  constraints,  transactions,  and  a 
mandatory  integrity  policy  [17,18].  Clark  and  Wilson  [19] 
argue  that  integrity  is  more  important  than  multilevel  se¬ 
crecy  in  most  commercial  environments,  and  go  on  to  argue 
that  such  a  policy  should  include  controls  that  enforce  sep¬ 
aration  of  duty  among  employees. 
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Privacy 

Computer  security  is  essential  for  enforcing  state  and  na¬ 
tional  privacy  laws.  At  the  same  time,  the  process  of  de¬ 
tecting  threats,  vulnerabilities,  and  abuses  may  resuit  in 
violations  of  privacy  and  other  human  rights,  leading  to  a 
conflict  between  the  use  of  computer  security  to  guarantee 
privacy  and  its  use  to  invade  privacy.  These  privacy  issues 
became  particularly  apparent  when  backup  files  for  a  com¬ 
puter  operated  by  the  National  Security  Council  were  used 
to  reconstruct  and  expose  electronic  mail  messages  regard¬ 
ing  the  Iran  arms  deal. 

One  area  where  this  conflict  is  especially  noticeable  is 
threat  monitoring  —  that  is,  analyzing  system  activity  with 
the  objective  of  detecting  computer  break-ins  and  abuse.  We 
have  identified  several  types  of  monitoring,  listed  in  order 
of  increasing  privacy  implications: 

1.  Continuous  authentication,  such  as  through  keystroke 
dynamics. 

2.  Monitoring  unusual  activity  on  the  system  through 
system  status  information  (e.g.,  tracking  password  fail¬ 
ures  and  looking  for  sudden  rises  in  system  or  network 
activity). 

3.  Maintaining  an  audit  trail  of  user  activity  for  the  pur¬ 
poses  of  enforcing  user  accountability.  User  events 
recorded  in  an  audit  trail  may  include  login  times  and 
locations,  commands  executed,  and  file  accesses.  This 
type  of  auditing  is  required  by  the  Criteria  [!]  for  sys¬ 
tems  that  arc  rated  at  the  level  of  C2  and  above. 

4.  Analyzing  user  events  as  recorded  in  an  audit  trail  in 
terms  of  abnormal  behavior,  where  “normal”  may  be 
defined  in  terms  of  a  user’s  past  behavior  or  in  terms 
of  acceptable  behavior.  Under  sponsorship  from  the 
Space  and  Naval  Warfare  Command  (SPAWAR),  we 
arc  developing  at  SRI  a  real-time  Intrusion-Detection 
Expert  System  (IDES)  that  would  detect  various  types 
of  intrusions  by  looking  for  abnormal  behavior  on  the 
system(20,2I|. 

5.  Monitoring  the  contents  of  files  and  messages  (e.g.,  as 
for  the  Iran  arms  case).  Any  backup  system  poten¬ 
tially  gives  a  mechanism  for  implementing  this  type 
inoiiitoriug,  though  they  are  generally  Dot  used  for 
this  purpose. 

G.  Complete  surveillance  of  a  user’s  terminal  session  — 
i.e.,  ail  information  tr'nsmitted  to  and  from  a  user’s 
terminal  (except  possibly  passwords).  Limited  forms 
of  surveillance  that  provide  this  type  of  monitoring 
have  been  installed  in  some  systems,  and  Clyde  Digital 
Systems  has  developed  a  surveillance  tool  called  the 
“Surveillance-Kernel.” 

Mouitoring  has  many  advantages.  For  example,  it  has 
been  used  to  catch  outsiders  who  have  broken  into  computer 
systems,  and  it  could  potentially  detect  other  forms  of  com 
puter  misuse  that  go  undetected  by  other  security  controls. 
Monitoring  might  be  especially  attractive  in  environments 
where  the  systems  themselves  lack  adequate  security  con¬ 
trols  commensurate  with  the  sensitivity  of  the  information 
handled  by  them.  By  protecting  confidential  information 


about  individuals  from  unauthorized  access,  monitoring  can 
help  enforce  privacy  rights  and  protect  information  assets. 

While  recognizing  the  benefits  of  monitoring,  we  have 
some  concern  that  monitoring  could  foster  a  chilling  and 
suspicious  attitude  in  the  working  environment,  especially 
if  it  is  misused.  Il>  paiticular,  the  users  could  feel  that  they 
are  not  considered  trustworthy  or  that  their  privacy  and 
other  rights  are  violated  [22] .  We  are  also  concerned  that 
threat  monitoring  could  have  an  escalating  eflec  as  addi¬ 
tional  monitoring  capabilities  are  developed  in  ord  r  to  pro¬ 
tect  against  a  wider  range  of  threats,  while  at  the  :  me  time 
the  user  community  becomes  increasingly  less  sati  ,k  i  with 
the  working  environment.  Further,  monitoring  can  aggra¬ 
vate  the  security  problem  if  the  data  that  are  accumulated 
are  sensitive  but  not  adeqviately  protected.  For  example, 
many  audit  logs  accidentally  expose  user  passwords,  such 
as  when  a  password  shows  up  instead  of  the  user  identi¬ 
fier.  Finally,  the  centralization  of  sensitive  audit  data  that 
is  not  otherwise  available  in  an  integrated  form  has  social 
implications. 

Because  real-time  threat  monitoring  systems  are  not  yet 
generally  available,  it  is  difficult  to  determine  the  extant  to 
which  these  concerns  are  justified.  We  can  get  some  in¬ 
sights  from  a  study  by  Irving,  Higgins,  and  Safayeni  [23]  on 
computerized  performance  monitoring,  which  showed  that 
“workers  perceive  increased  stress,  lower  levels  of  satisfac¬ 
tion,  and  a  decrease  in  the  quality  of  their  relationships 
with  peers  and  management  as  a  consequence  of  computer¬ 
ized  monitoring.”  At  the  same  time,  however,  those  authors 
found  that  the  cause  of  the  dissatisfaction  was  not  so  much 
the  monitoring  per  sc  as  that  “managers  overemphasize  the 
importance  of  quantity  [over  quality]  ...  in  evaluating  em¬ 
ployee  performance.”  Thus,  that  study  concluded  that  it 
is  “not  the  technology  itself,  but  rather  how  it  is  used  by 
management  that  determines  an  individual’s  reaction.” 

Wc  believe  that  any  threat  monitoring  must  be  carefully 
applied  to  preserve  the  rights  of  privacy  and  freedom  from 
intrusion,  and  avoid  creating  an  atmosphere  that  leads  to 
employee  and  other  user  dissatisfaction.  When  a  computer 
system  is  being  shared,  users  should  not  expect  that  they 
can  function  privately,  in  isolation;  yet  limits  must  be  put 
on  monitoring  lest  it  become  oppressive.  These  issues  might 
be  partially  resolved  by  comparisons  with  analogous  situa¬ 
tions  such  as  the  sanctity  of  employee’s  desks  and  lockers, 
inter-office  mail,  television  monitoring,  use  of  work-place  in¬ 
formants,  and  telephone  eavesdropping  practices.  If  suitably 
restricted  and  administered,  monitoring  of  computer  activ¬ 
ity  could  be  viewed  as  a  benefit  by  the  user  community  in 
much  the  same  way  that  security  monitoring  of  personal 
luggage  at  airports  iu  viewed  as  a  benefit  by  air  travellers. 

We  recommend  that  a  policy  be  developed  regarding 
threat  monitoring  that  addresses  such  areas  as  limits  on 
threat  monitoring,  use  of  the  results  obtained  from  moni¬ 
toring,  obtaining  informed  consent  of  users,  and  providing 
due  notice  of  intent  to  monitor.  The  development  of  a  mon¬ 
itoring  policy  should  not  be  limited  to  security  exports,  but 
should  involve  users,  as  well  as  psychologists,  sociologists, 
constitutional  lawyers,  and  human  rights  groups.  We  be¬ 
lieve  that  this  task  should  be  assigned  high  priority  in  order 
that  wc  do  not  find  ourselves  with  threat  monitoring  systems 
that  foster  racial  problems  in  the  work  place.  Our  ultimate 
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goal  must  be  to  create  an  atmosphere  that  motivates  people 
to  behave  responsibly  and  with  confidence  that  both  their 
rights  and  information  assets  are  protected. 

Protecting  Noncomputerized 
Information 

Although  our  society  is  still  heavily  dependent  on  informa¬ 
tion  that  is  spokeD  and  printed  on  paper,  we  often  ignore  the 
security  of  these  other  forms  of  information  in  favor  of  the 
technological  challenges  associated  with  automated  informa¬ 
tion.  Interviews  of  approximately  100  computer  criminals, 
while  not  necessarily  representative  of  all  loss  experience,  in¬ 
dicate  a  skewing  of  emphasis  across  all  forms  of  information 
[2d],  Except  for  some  of  the  malicious  hackers,  these  peo¬ 
ple  were  attempting  to  solve  their  intense,  unsharable,  per¬ 
sonal  problems  with  the  easiest,  safest,  and  surest  methods, 
constrained  by  their  own  skills,  knowledge,  and  resources. 
Their  preferred  forms  of  information  were  the  spoken  word 
first,  printed  information  second,  and  computerized  infor¬ 
mation  third.  Computerized  information  received  their  fo¬ 
cus  of  attention  only  when  the  other  forms  of  information 
were  not  accessible  to  them  or  amenable  to  their  knowledge 
and  skills[25).  They  did  not  need  the  computer  as  a  tool  to 
modify,  disclose,  or  manipulate  large  amounts  of  informa¬ 
tion. 

Protectors  of  information  must  assign  similar  priorities 
in  applying  security,  while  not  overlooking  computerized  in¬ 
formation  m  anticipation  of  the  few,  unusuai  pcipeliuiois 
who  do  not  fit  the  general  pattern.  Limited  security  re¬ 
sources  would  dictate  “spoof-proofing”  of  key  employees  so 
that  they  are  not  deceived  into  giving  information  to  out¬ 
siders  who  lack  a  necd-to-know,  and  protecting  printed  pa¬ 
per  and  removable  computer  media  before  protecting  infor¬ 
mation  stored  in  computers  or  data  communications  [26] 

Summary  and  Recommendations 

The  pursuit  of  technology,  in  the  absence  of  a  broad  policy 
that  addresses  the  social  aspects  of  computer  security,  op¬ 
erates  in  a  vacuum  that  may  lead  to  violations  of  human 
rights,  abuse,  or  other  unwanted  consequences.  Attention 
must  lie  given  to  the  social  aspects,  and  we  make  the  fol¬ 
lowing  specific  suggestions: 

1.  That  the  social  aspects  of  specific  computer  security 
policies  and  technologies  be  examined  in  depth.  Areas 
that  should  be  addressed  include  identification  and  au¬ 
thentication,  access  controls  (including  those  provided 
by  add-on  security  packages),  encryption,  and  throat 
monitoring.  The  technologies  should  be  examined  in 
terms  of  their  actual  and  perceived  effect  on  produc¬ 
tivity  and  privacy. 

2.  That  generic  security  policies  be  developed  for  differ¬ 
ent  types  of  organizations  and  environments,  taking 
into  account  the  social  aspects  of  information  protec¬ 
tion.  The  generic  policies  could  serve  as  guidelines  for 
formulating  specific  security  policies  within  an  organi¬ 
zation. 


3.  That  a  national  policy  be  developed  specifically  for 
threat  monitoring  that  recognizes  the  rights  of  the 
users  as  well  as  the  potential  threats. 

Even  though  the  emphasis  in  this  paper  is  on  the  so¬ 
cial  aspects,  it  is  vital  that  the  technological  and  the  social 
considerations  be  balanced.  They  must  go  hand  in  hand. 
Either  one  without  an  understanding  of  the  other  is  likely 
to  create  serious  problems. 

Moreover,  security  must  be  tempered  with  many  other 
requirements  that  we  have  not  addressed  here,  such  as  reli¬ 
ability,  safety  of  use,  and  real-time  responsiveness.  To  ad¬ 
dress  a  broad  spectrum  of  requirements  requires  a  holistic 
approach.  At  lower  layers  of  system  abstraction  we  tend  to 
optimize  rather  locally  to  ensure  that  the  technology  sat¬ 
isfies  rather  specialized  properties  such  as  file  privacy  and 
integrity.  At  the  higher  layers  the  optimization  may  produce 
completely  different  results  when  ail  of  the  requirements  are 
considered  (technological  and  human,  health  and  welfare, 
costs  of  automating,  costs  of  not  automating,  etc.)[27). 
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ABSTRACT 

The  primary  purpose  of  this  paper  is  to  pro¬ 
vide  academicians  with  both  motivation  and 
Ideas  for  bringing  ethics  formulation  into  the 
college  Computer  Science  or  Computer 
Information  Systems  classroom.  It  provides 
Some  mechanisms  for  introducing  the  topic  and 
discussing  its  importance.  It  further  pro¬ 
vides  some  fundamental  facts  and  documents 
that  are  basic  to  any  such  discussion. 


INTRODUCTION 

It  was  a  routine  morning  as  John  was  on  his 
key  to  his  Job  in  state  government.  Traffic 
vas  net  unusually  heavy  sher.  he  was  stopped  at 
the  light  at  a  busy  intersection.  For  some 
reason,  the  occupant  of  the  car  next  to  him 
caught  his  eye  and  his  imagination.  The  car 
vas  a  Mercedes  190o,  end  the  occupant  was  a 
atriking  young  woman  about  middle  thirties. 
Traffic  in  her  lane  moved  a  bit  faster  than 
hie,  and  he  was  further  intrigued  by  the  plate 
number  MINE. 

When  he  arrived  at  the  office,  he  did  all  the 
routine  early  morning  tasks  before  flipping  on 
his  computer  terminal.  Once  the  screen  was 
illuminated  and  he  was  logged  on  to  the  sys¬ 
tem,  however,  he  made  some  very  unusual 
requests  for  information.  By  accessing  the 
Department  of  Motor  Vehicles  database  and 
entering  that  plate  number,  he  quickly  learned 
the  young  woman's  name,  her  address,  vital 
statistics,  and  driver's  license  number  (which 
also  happened  to  be  her  social  security  num¬ 
ber).  He  then  accessed  various  databases  main¬ 
tained  by  state  and  local  government  and  was 
able  to  learn  the  following: 

From  the  State  Tax  Office  he  learned  her 
place  of  employment,  her  position,  and 
her  salary. 

From  the  Tax  Assessor's  Office  he  learned 
the  value  of  her  property  and  the  condi¬ 
tions  of  her  deed.  (A  Joint  ownership 
with  a  different  last  name  signaled  that 
she  was  divorced.  ) 

From  divorce  records  in  the  County 
Clerk’s  Office,  he  gained  information 
about  her  children,  and  he  learned  that 
she  had  another  previous  marriage  that 
had  terminated  in  divorce  in  Reno, 
Nevada. 

He  pondered  the  situation  a  few  momenta  before 
making  hie  next  move,  and  he  opted  for  check¬ 


ing  school  records  rather  than  linking  with 
the  State  Data  Exchange  Network  to  find  more 
details  about  this  first  marriage.  In  check¬ 
ing  school  records,  he  learned  names,  ages, 
and  academic  characteristics  of  her  two 
children. 

Before  abandoning  his  quest  for  information  on 
the  young  woman,  he  added  her  name  to  a  list 
of  legitimate  requests  for  unearned  income 
information  from  the  Internal  Revenue  Service. 
Within  a  few  days,  he  learned  that  during  the 
previous  year  she  had  earned  in  excess  of 
S4C,  000  from  investments,  rental  income, 
bonuses,  and  winnings  at  the  track. 

All  of  this  was,  indeed,  enough  to  convince 
her  that  a  friend  had  suggested  he  contact  her 
when  he  phoned  to  make  arrangements  for  a 
date. 


THE  FACTS 

The  story  you  have  Just  read  is  not  true.  It 
vas  a  scenario  aet  by  Pete  Early  in  his  arti¬ 
cle  "Prying  Eyes"  published  in  the  Louisville, 
Kentucky  COURIER  JOURNAL  MAGAZINE  on  July  20, 
19(36.  He  used  this  introduction  to  question 
the  legality  of  the  government's  role  in 
creating  such  database  linkage  capabilities. 
I  use  it  to  introduce  a  lively  classroom 
discussion  on  "Ethics  and  _he  Computer  Profes¬ 
sional.  " 

Computer  Security  Systems 

Did  he  violate  or  defeat  any  computer  security 
system?  To  answer  this  question,  it  is  neces¬ 
sary  to  consider  what  constitutes  a  security 
system. 

Figure  1  graphically  illustrates  the  various 
layers  of  computer  security,  the  first  of 
which  is  sound  company  policies  and  procedures 
for  access  and  use.  Because  this  layer  is 
somewhat  vague  and  arbitrary,  it  is  depicted 
with  a  broken  line.  This  is  a  very  vulnerable 
level  at  which  ethics  play  a  very  important 
role. 

Other  levels  include  environmental  control 
which  is  some  form  of  physical  isolation, 
hardware  control,  software  control,  and 
encryption.  The  first  two  layers  can  easily 
be  penetrated  if  the  computer  has  dial-up 
capabilities;  and  the  remaining  layers,  being 
devised  by  man,  can  be  defeated  by  man. 

Without  knowing  the  state  policies  and  proce¬ 
dures,  we  still  cannot  determine  if  John  vio¬ 
lated  thot  level.  It  ie  highly  likely  that  he 
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FIGURE  Is  LAYERS  OF  COMPUTER  SECURITY 


did.  We  can  determine  that  he  did  not  violate  negligence  and  cited  a  need  for  increased  con- 

other  levels  of  security.  He  was  an  insider  sciousness  of  their  responsibilities  C33. 

who  had  access  to  this  information  but  simply 

chose  to  use  hie  access  capability  in  a  some-  About  that  same  time,  Bess  Gallants  tbH  pub- 

what  questionable  manner.  lished  an  article  in  which  Bhe  stated: 

. . . as  quickly  as  security  systems  are 
designed,  ingenious  criminals  or  preco¬ 
cious  kids  seem  to  be  that  much  more 
challenged  to  find  a  weak  link  in  the 
security  chain.  Until  perfect  security 
is  designed,  the  future  lies  in  pending 
legislation  and  court  decisions  that  will 
define  specific  crimes  and  attach 
appropriate  penalties. 

John  Soma  17)  in  his  book  published  in  that 
same  year  wrote: 

Although  the  majority  of  computer  related 
cximes  are  basically  "the  same  crimes 
that  have  been  prosecuted  since  the  apple 
was  plucked,  "  it  is  difficult  to  match  a 
specific  crime  with  the  traditional 
criminal  statute. 

After  computer  crime  hit  Congress  with  the 
infiltration  of  computer  systems  belonging  to 
California  Representative  Ed  Zschau  and 
Arizona  Representative  John  McCain  early  in 
19B&  123,  legislative  response  was  strong  and 
swift.  Not  only  did  some  of  the  larger  states 


Did  he  break  any  lavs?  Again,  before  ve  can 
answer,  we  must  know  where  computer  crimes 
laws  exist  and  what  they  cover. 

Since  197Q  forty-seven  of  the  fifty  states 
have  enacted  specific  computer  crimes  legisla¬ 
tion.  Florida  has  the  oldest  law  and  New 
York,  Texas,  and  Indiana  have  the  newest. 
Many  of  these  laws  did  not  come  easy. 


At  the  ACM  Conference  in  New  York  in  1883, 
there  was  lively  discussion  on  the  pros  and 
cone  of  such  lavs.  Kenneth  Thompson  of  Bell 
Labs  claimed  that  the  media  was  causing  legis¬ 
lation  to  start  popping  up  in  state  legisla¬ 
tures  that  would  impose  heavy  criminal  penal¬ 
ties  for  unauthorized  access  to  computers  that 
were  an  unnecessarily  harsh  response  to  acts 
that  were  more  like  "computer  joy  riding. *  He 
recommended  simple  instruction  for  youngsters 
that  such  activities  were  akin  to  vandalism 
and  should  not  be  practiced.  David  Brandon, 
then  President  of  ACM,  charged  people  who 
operate  unprotected  systems  with  contributory 
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quickly  enact  lave,  Congress  passed  two  bills 
to  amend  Title  18r  United  State©  Code.  The 
Computer  Fraud  and  Abuse  Act  of  1986  which 
became  Public  Law  No:  99-474  on  October  16, 
1985  provides  additional  penalties  for  fraud 
and  related  activities  in  connection  with 
access  devices  and  computers.  The  Electronic 
Communicat ions  Privacy  Act  of  1986  which 
became  Public  Law  No;  99-508  on  October  21, 
19Q6  amended  the  Federal  criminal  code  to 
extend  the  prohibition  against  the  unauthor¬ 
ized  interception  of  communications  to  include 
specific  types  of  electronic  communications  in 
addition  to  the  interception  of  wire  and  oral 
communication  only. 

Since  he  opted  not  to  access  the  State  Data 
Exchange  Network  and  he  did  not  use  a  computer 
to  gain  information  from  the  IRS,  it  is  rea¬ 
sonable  to  assume  that  John  did  not  violate 
the  aforementioned  Federal  law;  but  the 
question  still  remains  as  to  whether  or  not  he 
violated  a  state  statute.  Since  the  story 
originated  in  Kentucky,  consider  how  he  would 
fare  in  light  of  the  Kentucky  legislation. 


The  following  excerpts  from  the  Kentucky 
Revised  Statutes  434.840  -  434.860  may  yield 
some  insight  at  that,  level. 

KRS  434.840  -  434.860 

434.840.  Definitions.--  .  .  . 

434.845.  Unlawful  access  to  a  computer 
in  the  firBt  degree.  --  <J>  A  person  is 
guilty  of  unlawful  access  to  a  computer 
in  the  first  degree  when  he  knowingly  and 
willfully,  directly  or  indirectly,  causes 
to  be  accessed,  or  attempts  to  access  any 
computer  software,  computer  program, 
data,  computer  system,  computer  network, 
or  any  part  thereof,  for  the  purpose  oi : 

(a)  Devising  or  executing  any  scheme 
or  artifice  to  defraud;  or 

<b>  Obtaining  money,  property,  or 
services  .  .  . 

<3>  Unlawful  accesc  to  a  computer  in  the 
first  degree  is  a  Class  C  Felony. 


CRlfCS  AND  PUNISHMENTS 


CHAPTER  108  * 

Substitute  for  House  Bill  No.  2044 


AN  ACT  relating  to  cnoes  and  pumshaems;  concerning  computer  erioe  and  unlawful  coaputer  accvss;  classifying 
certain  acts  as  aisdeaeanors  and  felonies. 

Be  it  e  ^cted  by  the  Legislature  of  the  State  of  Kansas: 

Section  1.  (11  As  used  in  this  section,  the  following  words  aid  phrases  shall  have  the  aeamngs  respec¬ 

tively  ascribed  thereto: 

(a)  “Access"  weans  to  approach,  instruct,  eoowunicate  with,  store  date  in,  retrieve  drU  frou,  or  other'Mis-i 
aak.p  use  of  any  resources  of  a  computer,  coaputer  systea  or  computer  network. 

(b)  “Computer*  weans  an  electronic  device  which  performs  *ork  uriing  prograwKti  inst<  :tion  art  which  ha., 
one  or  wore  of  the  capabilities  of  storage,  logic,  arithmetic  0"  complication  and  includes  *11  input,  o.tput, 
processing,  storage,  software  or  ctwiunicalion  facilities  which  are  connected  or  related  '.•>  such  a  device  in  a 
systea  or  network. 

(c)  “Computer  network'  Beans  the  interconnection  of  cooaunication  lines,  inrlud*.ng  airrcwuve  or  other  weans 
of  electronic  cooaunication,  with  a  computer  through  remote  terainal*-  or  a  coaplex  consisting  of  two  or  •ore 
interconnect ad  coaputers. 

(d)  'Cooputer  prograa’  Beans  a  series  of  instructions  or  stateoe.ito  in  a  fora  acceptable  to  a  coaputer 
which  pemits  the  functioning  of  a  computer  systea  in  c  tanner  designed  to  provide  appropriate  products  fro* 
such  coaputer  systea. 

(e)  'Coaputer  softwar"’  ans  coaputer  prograis,  procedures  and  associated  documentation  concerned  with  th? 
operation  of  a  coaputer  .d. 

(?)  "Coaputer  systea’  Uwdns  a  set  of  related  coaputer  eqmposr.t  or  devices  a><J  coteputpr  software  which  aay 
be  connected  or  unconnected. 

(g)  ’‘Financial  instrument'  aeans  any  check,  draft,  aorvy  order,  certificate  uf  deposit,  letter  of  credit, 
bill  of  exchange,  credit  card,  debit  card  or  aarketable  security. 

(h)  'Property1  includes,  but  is  not  Halted  to,  financial  nsvruaonts,  infonMt’on,  electron  rally  produced 
on  stored  data,  supporting  documentation  and  coaputer  software  in  either  tirSune  or  huaan  readaole  fona  and 
any  other  tangible  or  intangible  itea  of  value. 

h)  “Services"  includes,  but  is  not  Halted  to,  coaputer  tiae,  deta  processing  and  storage  functiors  and 
other  uses  of  a  coaputer,  coaputer  systea  or  coaputer  r*twork  to  pe>*fon»  useful  work. 

(j)  "Supporting  docuaentation'  includes,  but  is  nut  liB't«o  to,  all  (iocufcefitation  used  in  the  construction, 
classification,  ispleaentatinn,  use  or  modification  of  coaputer  software,  coaputer  prograns  or  data. 

(?)  Coaputer  cnae  is: 

(a)  Willfully  and  without  authorization  gaining  or  attempting  to  gain  access  to  and  daaaging,  aaiifying, 
altering,  destroying,  copying,  disclosing  or  taking  possession  of  a  coaputer,  coaputer  systea,  coaputer  net¬ 
work  or  any  other  property; 

(b)  using  a  coaputer,  coaputer  systea,  coaputer  network  or  Any  other  property  for  th?  purpose  of  devising 
or  executing  a  scheae  or  artifice  wit^  *’  ;ntent  to  defraud  or  for  the  purpose  of  obtaining  acne/,  property, 
services  or  any  other  th  f  value  .  'of  false  or  fraudulent  pretense  nr  representation;  or 

ic)  willfully  ■.  .  iiu't  .  orization  and  damaging,  ondifying,  altering,  destroying,  copying, 

disclosing  or  taki..;  .  ^session  of  coaputer,  coaputer  systea,  coaputer  network  or  Ary  oth*r  property. 

Coaputer  cnae  which  causes  a  loss  of  the  value  of  less  than  $150  is  a  class  A  eisdeoeanor. 

Coaputer  cnae  which  causes  a  loss  of  the  value  of  $150  or  acre  is  a  class  E  felony. 

(3)  In  any  prosecution  for  coaputer  cnae,  it  is  a  defense  (hat  the  property  or  services  were  app- «cnated 
openly  and  avowedly  under  a  claia  of  title  made  in  good  faith. 

(4)  Unlawful  coaputer  access  is  willfully,  fraudulently  and  without  author! tat  ion  gaming  or  attempting  to 
gain  access  to  any  coaputer,  computer  systea,  computer  network  or  to  any  coaputer  software,  prograa,  docuaen- 
tat  ion,  data  or  property  contained  in  any  coaputer,  coaputer  systea  or  coaputer  network. 

Unlawful  coaputer  access  is  a  class  A  ",'**v»anor. 

(5)  This  section  shall  be  part  of  and  mental  to  the  Kansas  cnainal  code. 

Sec.  ?.  This  act  shall  take  effect  *...  in  force  froa  and  after  its  publication  in  the  statute  book. 

Approved  April  IB,  1S85 


FIGURE  2  x  CRIMES  AND  PUNISHMENT,  Chapter  108 
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Had  he  been  in  Pennsylvania,  Title  IQ,  Section 
3933  UNLAWFUL  USE  OF  COMPUTER  states; 

(a)  OFFENSE  DEFINED  -  A  person  commits 
an  olfense  il  he: 

(1)  accesses,  alters,  damages  or 
destroys  any  computer,  computer  system, 
computer  network,  computer  software, 
computer  program  or  data  base  or  any  part 
thereof,  with  the  intent  to  interrupt  the 
normal  functioning  of  an  organization  or 
to  devise  or  execute  any  scheme  or 
artifice  to  defraud  or  deceive  or  control 
property  or  services  by  means  of  false  or 
fraudulent  pretenses,  representations  or 
promises;  or 

<2>  intentionally  and  without 

authorization  alters,  damages  or  destroys 
any  computer,  computer  system,  computer 
network,  computer  software,  computer 
program  or  computer  data  base  or  any  part 
thereof . 

It  is  still  not  clear  cut.  He  did  use  a 
computer  to  access  data,  but  did  he  have  plana 
to  ci.»frnuc'  cr  obtain  monsvy,  property,  or 
services?  We  could  exami.ie  the  definition  of 
defraud,  a  word  which  occi.ru  in  virtually  all 
o.t  the  o tytr  1  avda . 

DEFRAUD  -  To  deprive  of  some  right, 
interest,  or  property  by  duveit..  —  Syn. 
See  CHEAT* 

There  are  irony  fiimiloriti  ed  x:\  the  various 
state  laws.  There  are  also  =?omi>  very  inter¬ 
esting  differences  in  them.  North  Carolina 
excludes  er.hsMe'fi  '"to  obtain  educational  test¬ 
ing  material,  a  false*  educational  testing 
oc.ore,  or  false  academic  or  vocational  grade" 
for  consideration  oe  fraud  and  classification 
an  a  fejony;  arc!  North  Dakota  specifically 
mentions  "violation  of  daca  piooeneing  inloi 
matron  confidentiality."  Georgia  cays  th^ 
duty  to  report  violations  is  coupled  with 
immunity  from  sr«y  civil  JiR.bili.ty  lor  such 
reporting . 

The  Kansas  Lav,  which  is  not  atypical  but  Ls 
somewhat  more  brie*  than  tn?ny,  is  included  in 
its  entirety  in  Figure  2  as  a  sample  of  a 
complete  piece  of  computer  crimes  legislation. 

Was  he  guilty  of  fraud  or  did  he  simply  satis¬ 
fy  his  normal  curiosity?  We  would  need  to 
know  mure?  of  the  story,  end  then  we  would 
probably  st..U  1  need  to  deliberate  a  very  long 
time. 

UAvac.Y-.LcolgcU.aft 

Did  ho  Invade*  her  privacy?  Surely,  this  an¬ 
swer  is  1,yeG*  !  Bui,  does  aha  have  any 
protection  against  this  type  of  invasion  of 
privacy'.' 

Two  hundred  years  ago  Thornes  Jefferson  said: 

. . .  laws  and  Institutions  must  go  hand  in 
hand  with  the  human  mind. . .  As  new  dis¬ 
coveries  aro  made,  now  truths  disclosed, 
and  manners  and  opinions  change  with  the 
cl ruvnibt ranees,  institutions  must  advance 
aleo,  and  keep  pace  with  the  times. 

In  ]  flc;0,  Supreme  Court  Justice  Louis  Brandeis 
3tetod  that  "the  right  to  be  Jet  alone  ib  one 


of  the  most  comprehensive  of  rightB  and  the 
most  valued  by  civilized  man. " 

Nov  there  are,  indeed,  some  federal  laws  that 
relate  to  privacy.  The  Fair  Credit  Reporting 
Act  of  1970  which  regulates  credit  bureaus; 
the  Freedom  of  Information  Act  of  1970  which 
permits  individuals  to  have  access  to  data  on 
them  contained  in  federal  agency  files;  the 
Education  Privacy  Act  which  pertains  to  cer¬ 
tain  practices  of  federally  funded  educational 
institutions;  the  Privacy  Act  of  1974,  the 
introduction  of  which  is  contained  in  Figure 
3,  which  provides  certain  safeguards  for  Indi¬ 
viduals  against  an  Invasion  of  personal  priva¬ 
cy  by  federal  agencies;  the  Right  to  Financial 
Privacy  Act  of  1978  which  restricts  government 
access  to  certain  records  held  by  financial 
institutions;  and  the  Electronic  Funds  Trans¬ 
fer  Acts  of  1979  and  1900  which  outline 
responsibilities  of  companies  using  EFT  are 
among  them.  These  laws,  however,  govern  only 
the  actions  of  federal  agencies  or  agencies 
who  receive  funds  from  the  federal  government. 

fiany  of  the  states  also  have  laws  relating  to 
privacy,  and  these  laws  were  quite  often  en¬ 
acted  well  in  advance  of  computer  crimes  laws. 
Again,  however,  most  do  not  specifically  cite 
invasion  of  privacy  as  it  relates  to  computers 
and  databases;  and  interpretation  of  guilt 
under  such  laws  would  be  uncertain. 

Few  infor nation  privacy  violation  cases  have 
been  litigated.  Since  we  do  not  know  what  is 
accumulated,  stored,  and  transferred  pertain¬ 
ing  to  us  and  it  is  not  likely  that.  we  will 
ever  know,  we  are  unlikely  to  pnmue  such  a 
matter.  If  we  go  to  court  to  protect  our  pri¬ 
vacy  everyone  will  know  everything.  Is  the 
gain  worth  the  risk?  Probably  not. 

If  accused,  then,  could  John  be  convicted  of 
invasion  of  privacy?  That,  too,  ls  doubtful. 


THE  FUNDAMENTALS 
Professional  Ethics 

Would  his  actions  be  considered  ethical  among 
computer  professionals?  Before  deciding,  we 
should  consider  statements  pertaining  to 
ethics  In  the  Computer  Science  and  Computer 
Information  Systems  literature. 

Definitions 

ETHICS  -  A  treatise  on  morals;  the 
science  of  moral  values  and  duties;  the 
study  of  ideal  human  character,  actions, 
and  ends;  moral  principles,  quality,  or 
practice.  (Webster's  New  Collegiate) 

ETHICS  -  A  system  of  moral  principles; 
the  rules  of  conduct  recognized  in 
respect  to  a  particular  class  of  human 
actions  or  to  a  particular  group,  cul¬ 
ture,  etc. ;  moral  principles;  that  branch 
of  philosophy  dealing  with  values  per¬ 
taining  to  human  conduct  with  respect  to 
the  lightness  and  wrongness  of  certain 
actions  and  to  the  goodness  and  badness 
of  the  motives  and  ends  of  such  actions, 
(Random  House  Unabridged) 
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PRIVACY  ACT  OF  1974 


INTRODUCTION 

Thp  purpose  of  this  art  is  to  provide  certain  safeguards  for  individuals  against  an  invasior»  if  personal  pri¬ 
vacy  by  requiring  Federal  agencies,  except  as  otherwise  provided  by  law,  to: 

i.  Permit  an  individual  to  detenu  ne  what  records  pertaining  to  hm  are  collected,  Maintained,  used  or  dis¬ 
seminated  by  sucb  agencies. 

?.  Perait  an  individual  to  prevent  records  pertaining  to  hi*  obtained  by  such  agencies  for  a  particular  pur¬ 
pose  fro*  being  used  or  *ade  available  for  another  purpose  without  his  consent. 

3.  Per*it  an  individual  to  gain  access  to  information  pertaining  to  hi*  in  federal  agercy  records,  to  have  a 
copy  of  all  or  any  portion  thereof,  and  to  correct,  or  amend  such  records. 

4.  Collect,  Maintain,  use  or  disseminate  any  record  of  identifiable  personal  information  in  a  manner  that 
assures  that  such  action  is  for  a  necessary  and  lawful  purpose,  that  the  information  is  current  ard  accurate 
for  its  interred  use,  arid  that  adequate  sateguards  are  provided  to  prevent  misuse  of  such  information, 

5.  Permit  exemptions  fro*  the  requirements  with  respect  to  records  provided  for  in  this  act  only  in  those 
cases  rtiere  there  is  &n  important  public  need  for  such  exemption  as  has  been  determined  by  specific  statutory 
authority. 

6.  Be  subject  to  civil  suit  for  any  damages  which  occur  as  a  result  of  willful  or  intentional  act  ion  which 
violates  any  individual’s  rights  under  this  act. 

The  PRIVACY  ACT  OF  1974  applies  to  all  federal  agencies  except  the  CIA  and  law  enforcement  agencies. 


FIGURE  3:  PRIVACY  ACT  OF  1974 


We  live  In  an  age  and  in  a  society  where 
morality  and  ethics  seem  to  be  eroding  more 
each  day.  We  are  amazed  when  ve  read  the  ever 
groving  accounts  of  questionable  behavior  on 
the  part  of  prominent  and  not  so  prominent 
members  of  our  society.  We  shake  our  heads 
and  role  our  eyes  vhen  ve  read  of  unethical 
philander inge,  but  we  do  little  or  nothing 
difinitive  to  bring  about  significant  change 
lu  Ruch  behaviors.  We  read  and  relate  the 
accounts  which  glorify  such  behavior,  and  we 
buy  tickets  and  attend  lectures  to  hear  former 
convicted  felons  present  the  rational  for 
their  unethical  and/or  criminal  behavior. 

In  hay  1984,  COMPUTERS  and  PEOPLE  carried  an 
article  titled  "Lack  of  Ethics  as  a  Cause  for 
Computer  Crime"  which  was  excerpted  from 
Chapter  6  of  HOW  TO  PREVENT  COMPUTER  CRIME  by 
AuguBt  Bequai.  It  exhibited  the  Table  of 
Contents  of  the  book  and  then  began: 

Lack  of  Ethics 

A  computer  programmer  attempts  to  sell 
valuable  software  belonging  to  hia  em¬ 
ployer  to  one  of  its  competitors.  When 
discovered,  the  employer  ie  reluctant  to 
prosecute;  it  1b  rumored  that  the  pro¬ 
grammer  threatened  to  "blow  the  whistle" 
on  corrupt  company  practices.  An  execu¬ 
tive  embezzles  more  than  £400, 000  of  hie 
company's  assets  through  the  use  of  its 
computer.  When  the  auditors  uncover  his 
fraud,  hia  employer  simply  asks  for  his 
resignation;  it  is  said  that  dishonest 
conduct  was  a  "way  of  life*  at  the  com¬ 
pany.  A  computer  operator  usee  a  hospi¬ 
tal's  computer  to  steal  more  than 
620, 000;  the  victim  is  reluctant  to  pro- 
aecute.  It  1b  alleged  that  an  investiga¬ 
tion  would  have  led  to  exposure  of  thefts 
of  drugs  involving  hospital  personnel. 

The  above  examples  serve  to  illustrate 
two  key  points:  first,  that  crime  by 
dishonest  employees  has  reached  epidemic 
proportions  ...  ;  and  second,  that  some 
victims  are  reluctant  to  prosecute* 
because  they  have  their  own  "skeletons" 
to  hide.  .  .  . 


Other  subheadings  included: 

Law  of  the  Jungle 

Glorifying  the  Computer  Criminal 
We  Ill-Treat  "Whistleblowers" 

Role  of  Ethics 

Need  for  Ethical  Management 

Implementing  a  Code 

A  model  Code 

Teatiny  your  Code 

He  cited  a  study  by  the  Ethics  Resource  Center 
of  Washington,  D- C. ,  that  "confirmed  that, 
although  top  management  occasionally  pays  lip 
service  to  the  need  for  ethics  in  the  work¬ 
place,  little  is  dene  to  carry  this  out. "[11 

Robbin  JuriB  (61,  Associate  Editor  of  COMPUTER 
DECISIONS,  claimed  in  his  article  "Keeping  Cut 
the  Insiders"  that  "security  breaches  by 
outsiders  may  be  obscuring  a  much  greater  risk 
to  corporate  computer  systems:  the  threat 

from  within. "  Only  clearly  stated  company 
policies  end  procedures  and  ethical  conduct  of 
legitimate  users  will  eliminate,  or  at  least 
reduce,  such  security  breaches  from  inside. 

Both  the  Association  for  Computing  Machinery 
(ACM)  and  the  Data  Processing  Management 
Association  <DPMA>  have  made  positive  and 
definitive  statements  pertaining  to  profes¬ 
sional  ethics.  Excerpts  from  BYLAW  19,  ACM 
CODE  OF  PROFESSIONAL  CONDUCT  are  included  in 
Figure  4.  The  entire  DPMA  Code  of  Ethics  is 
presented  in  figure  S. 

Note  that  the  ACM  code  begins: 

PREAMBLE 

Recognition  of  Professional  Status  by  the 
public  depends  not  only  on  skill  and 
dedication  but  also  on  adherence  to  a 
recognized  Code  of  Professional  Conduct. 

DPMA  chooses  to  begin  its  CODE  OF  ETHICS  with 
a  statement  of  obligation  to  management,  to 
fellow  members,  to  society,  to  employer,  and 
to  country.  The  STANDARDS  OF  CONDUCT,  then, 
specify  the  responsibilities  of  each  of  these 
obi igatione. 
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la  light  of  these  presentations,  was  he  guilty 
of  a  bieach  of,  ethics'?  Did  he  violate  any 
subjection*  of  either  CANON  1  or  CANON  5  of 
the  ACl?  code?  Is  there  an  ir*fx  faction  against 
the  DPHA  cede?  If  hir»  activities  ve re  known, 
would  he  he  disciplined  for  hie  actions  by  one 
of  these  prof eociona )  uescciatioms?  As  com¬ 
puter  professionals,  how  should  we  react  to 
such  behavior  in  our  ranke? 


Virtually  every  college  textbook  for  use  in 
introductory  information  systems  courses  has 
cne  or  more  chapters  devoted  to  social  issues 
and  implications.  host  have  at.  least  a  brief 
discussion  relating  to  ethics.  Texts  for 
introductory  computer  science  courses  contain 
chapters  on  file  processing  and  occasionally 
make  reference  to  data  security  and  integrity. 


B/uw  19.  j&ysLOF  JMf  ssi  gwBLCQNDgcT 

PRtAAkl 

Recognition  Of  professional  sta.us  by  the  public  depends,  not  only  on  gull  end  dedication  but  disc  on 
jdher?».co  to  a  recognized  code  of  Professional  Conduct.  The  folloni.iy  Code  seis  the  general  principles 
(Canons),  professional  ideals  (Ethical  Considerations),  and  mandatory  rules  (Disciplinary  Ryles)  applicable  to 
each  ACM  Member. 

The  I'frrbs  ‘'shall”  (imperative;  3nd  "should11  (encouragement)  are  used  purposefully  in  thy  Code.  The  Canons 
ana  ethical  Considerations  are  not,  howver,  billing  rjles.  Each  Disciplinary  Rule  is  binding  on  each  Member 
of  ACM.  Failure  to  observe  the  disciplinary  rules  subjects  the  Member  to  admonition,  suspension  or  expulsion 
from  the  Association  as  provided  by  the  Procedures  for  the  Enforcement  of  the  ACM  Code  of  Professional 
Conduct,  which  specified  in  the  PCM  Policy  and  Procedures  Guidelines.  The  term  "member (s) "  is  used  in  the 
Code.  The  Disciplinary  Rules  apply,  however,  only  to  the  classes  of  membership  specified  in  Article  3, 
Section  5,  of  the  Constitution  of  the  ACM.  li.e.  members  with  voting  rights! 

CANON  1 

An  ACM  member  shall  act  at  all  times  with  integrity. 

Ethical  Consideration 

ECl.i  An  ACM  member  shall  properly  qu0’ity  himself  when  expressing  &f.  opinion  outside  his  areas  of 
c;a pet once.  A  member  is  encouraged  to  express  his  opinions  on  subjects  within  his  area  of  competence. 
ECl.i?  fir.  ACM  member  shall  preface  any  parti*»:n  statements  about  information  processing  by  indicating 
clearly  on  whose  behalf  they  are  made. 

EC1.3  An  ACM  mernbe-  shall  act  faithfully  on  behalf  of  his  employers  or  clients. 

Disciplinary  Ruler. 

Ml*  1.2  £r,  ACM  SFvber  shall  r.v\t  ::&cs£icr.*!ly  “’^represent  his  q"ihf  icationn  or  credentials  to  pre¬ 
sent  or  prospective  employers  or  clients. 

Ml.  1.2  An  ACM  member  shall  not  make  deliberately  fal**  of  deceptive  statements  as  to  the  present  or 
exported  state  of  affairs  in  any  aspect  of  tne  capability,  delivery,  or  use  of  information  processing 
systems. 

Ml. 2. 1  An  ACM  member  shall  nov  intentionally  conceal  or  misrepresent  on  whose  behalf  any  partisan 
statements  are  wade. 

Ml. 2,1  An  ACM  wewber  acting  or  employed  as  a  consultant  shall,  prior  to  accepting  information  from 
a  prospective  client,  inform  tne  client  of  all  factors  of  which  the  member  is  aware  irfucti  may  affect 
the  proper  performance  of  the  task. 

Ml. 3.2  An  ACM  member  sha'l  disclose  any  interest  of  which  he  is  aware  which  does  or  may  conflict 
with  fcjs  duty  to  a  present  of  prospective  employer  or  client. 

Ml. 3.3  An  ACM  member  shall  not  use  any  confidential  information  from  any  employer  or  client,  past  or 
present,  without  prior  permission. 

CANON  2 

An  ACM  me*  .•  should  strive  to  increase  his  competence  and  the  competence  and  prestige  of  the  profession. 
CANON  3 

An  ACM  member  shall  accept  responsibility  for  his  work. 

CANON  4 

An  ACM  member  shall  act  with  professional  responsibility. 

CANON  5 

An  ACM  member  should  use  his  special  knowledge  and  skills  for  the  advancement  of  human  welfare. 

Ethical  Considerations 

EC5. 1  An  ACM  member  should  consider  the  health,  privacy,  and  general  welfare  of  the  public  in 
performance  of  his  work. 

EC5.R  An  ACM  member,  whenever  dealing  with  data  concerning  individuals,  shall  always  consider  the 
principle  of  the  individual’s  privacy  and  seek  the  following: 

*  To  minimize  the  data  collected. 

*  To  limit  authorized  arcess  to  the  data, 
a  To  provide  proper  security  for  the  data. 

*  To  determine  thp  required  retention  period  of  the  data. 

*  To  injure  proper  disposal  of  the  data. 

Disciplinary  Rules 

DR5.2.1  An  ACM  member  shall  express  his  professional  opinion  to  his  employers  or  clients  regarding 
any  adverse  consequences  to  the  public  whirh  wight  result  from  the  work  proposed  him. 


FIGURE  4:  ACM  CODE  OF  PROFESSIONAL  CONDUCT  (exc«rpta) 
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Database  and  file  proce^aing  couraea,  system 
design  and  analysis,  and  others  have  very  good 
entry  points  for  in-depth  discussions  relating 
to  ethics  and  ths?  computer  professional. 

Introducing  the  topic  at  a  reasonable  point  in 
the  overall  course  plan  yields  an  acceptance 
of  the  relevance  of  Buoh  a  discussion  in  the 
classroom.  It  is  then  up  to  the  Instructor  to 

CODE  OF  ETHICS 


capitalize  on  that  moment.  A  scenario  such  as 
presented  in  this  paper  provides  an  excellent 
springboard.  We  can  relate  to  this  situation. 
We  can  put  ouraeJ ves  in  the  position  ol  either 
the  young  man  or  the  young  woman.  We  can 
reflect  on  what.  we  would  do  in  a  similar 
situation  and  what  our  reaction  would  be  to 
the  possibility  that  someone  could  gain  so 
much  information  about  us  so  readily. 


I  acknowledge: 

That  I  have  an  obligation  to  Management,  therefore,  1  shall  promote  the  understanding  of  informat ion  pro¬ 
cessing  methods  and  procedures  to  Management  using  every  resource  at  my  cowman.. 

That  1  have  an  obligation  to  my  fellow  members,  therefore,  1  shall  upheld  the  high  ideals  of  D^Mfi  as  out  ¬ 
lined  in  its  international  Dylans.  Further,  J  shall  cooperate  with  ny  fellow  members  ano  shall  treat  them 
with  honesty  and  respect  at  ell  tines. 

That  1  have  an  obligation  to  society  and  hi i 1  participate  to  the  best  of  ny  ability  in  the  oissemi nation 
of  knowledge  pertaining  to  the  general  dcvelopner.t  and  understanding  of  information  processing.  Further,  I 
shall  not  use  knowledge  of  a  confidential  nature  to  further  ay  personal  interest,  nor  shall  1  violate  the  pri¬ 
vacy  and  confidentiality  of  information  entrusted  to  no  or  to  which  I  may  gam  access. 

That  1  have  an  obligation  to  my  employer  whose  trust  I  hold,  therefore,  1  shall  endeavor  to  discharge  tins 
obligation  to  the  best  of  ry  ability,  to  guard  ny  employer's  mtei'ests,  and  to  advise  him  or  her  wisely  ana 
honestly. 

That  I  have  an  obligation  to  my  country,  therefore,  in  my  personal,  business  and  social  contacts,  1  shall 
uphold  «y  nation  and  shall  honor  the  chosen  way  of  life  of  my  fellow  citizens. 

1  accept  these  obligations  as  a  personal  responsibility  and  as  a  member  of  this  association,  1  shall 
actively  discharge  these  obligations  and  I  dedicate  myself  to  that  end. 

STANDARDS  OF  CONDUCT 

These  standards  expand  on  the  Code  of  Fthics  by  providing  specific  statements  of  behavior  in  support  of  each 
element  of  the  Code.  They  are  not  objectives  to  be  strived  for,  they  are  ~ulcs  that  no  professional  will  vio¬ 
late.  It  is  first  of  all  expected  that  information  processing  professionals  will  abide  by  the  appropriate 
laws  of  their  country  and  community.  The  following  standards  address  tenets  that  apply  to  the  profession. 

In  Recognition  of  Ny  Obligation  to  Management  I  Shall: 

*  Keep  my  personal  knowledge  up  to  daU  df.d  insure  that  pioper  eupt.tise  is  available  when  nt-edml. 

*  Share  my  knowledge  with  others  and  present  factual  and  objective  information  to  management  to  the  best  of 
*y  ability. 

*  Accept  full  responsibility  for  work  that  I  perform. 

*  Not  misuse  the  authority  entrusted  to  me. 

*  Not  misinterpret  or  withhold  information  concerning  the  capabilities  of  equipment,  software,  or  systems. 

*  Not  take  advantage  of  the  lack  of  kncwlpdge  or  inexperience  on  the  part  of  others. 

In  Recognition  of  Ny  Obligation  to  Ny  Fellow  Members  and  the  Profession  I  Shall: 

*  Be  honest  in  all  my  professional  relat lonships. 

*  Take  appropriate  action  in  regard  to  any  illegal  or  unethical  practices  that  come  to  my  attention.  How¬ 
ever,  I  will  bring  chargps  against  any  person  only  when  1  have  reasonable  basis  for  believing  in  the  truth 

of  the  allegation  and  without  regard  to  personal  interest 

*  Endeavor  to  share  my  special  knowledge. 

*  Cooperate  with  others  in  achieving  understanding  and  in  identifying  problems. 

*  Not  use  or  take  credit  for  the  work  of  others  without  specific  acknowledgement  and  authorization. 

*  Not  takp  advantage  of  the  lack  of  knowledge  or  inexperience  on  the  part  of  others  for  personal  gain. 

In  Recognition  of  Ny  Obligation  to  Society  I  Shall: 

*  Protect  the  privacy  and  confidentiality  of  all  information  entrusted  to  me. 

*  Use  my  skill  and  knowledge  to  inform  the  public  in  all  areas  of  ny  expertise. 

*  To  the  best  of  my  ability,  insure  that  the  products  of  iry  work  are  used  in  a  socially  responsible  way. 

*  Support,  respect  arid  abide  by  the  appropriate  local,  stave,  provincial,  and  federal  laws. 

*  Never  misrepresent  or  withhold  information  that  is  germane  to  a  problem  or  situation  of  public  concern  nor 
will  1  allow  any  such  known  information  to  remain  unchallenged. 

*  Not  use  knowledge  of  a  confidential  or  personal  naturp  in  any  unauthorized  manner  or  to  achieve  personal 
gain. 

In  Recognition  of  Ny  Obligation  to  Ny  Employer  I  Shall: 

*  Hake  every  effort  to  ensure  that  I  have  the  most  current  knowledge  and  that  proper  expertise  is  available 
when  needed. 

*  Avoid  conflict  of  interest  and  insure  that  any  employer  is  aware  of  any  potential  conflicts. 

*  Present  a  fair,  honest,  and  objective  viewpoint. 

*  Protect  the  proper  interests  of  my  employer  at  all  times. 

*  Protect  the  privacy  and  confidentiality  of  all  information  entrusted  to  «?. 

*  Not  misrepresent  or  withhold  information  that  is  germane  to  the  situation. 

*  Not  attempt  to  use  the  resources  of  my  employer  for  personal  gain  or  for  any  purpose  without  proper 
approval. 

*  Not  exploit  thP  weakness  of  a  computer  system  for  personal  gain  or  personal  satisfaction. 


FIGURE  5 :  DPKA  -  CODE  OF  ETHICS  and  STANDARDS  OF  CONDUCT 
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Library  aso  1  gnment a  followed  hy  group  iiiucuii- 
f5iun  l'1  the  raual  i  n If  i  eating  art  urlcsj  is 
especially  benoficial.  A  note  o.t  caution# 
huwwoi  .  The  lnsli  ui'.im  must  be  sui  t’  where 
he/ s’ne  stands  on  aui-h  issues  and  be  ready  to 
1  lelil  vyj  y  pointed  questions  about  personal, 
values.  The  day  alter  such  a  di&iu&eion  in 
one  oi  my  classes  a  student,  asked  me  about  my 
feelings  on  copying  software.  This  could  be 
very  touchy#  but  they  deserve  honest  answers. 

Congressman  Zschau  12 J  was  quoted  as  saying 
that  the  mill  traUon  of  his  computer  system 
was  "tantamount  to  someone  breaking  into  my 
office#  taking  my  files  and  burning  them# "  but 
there  was  no  physical  evidence  of  such  a 
break  “in  arid  fire.  "Because  people  don't  see 
the  files  overturned  or  a  pile  of  ashes  out- 
tside  the  door,  it  doesn't  seem  so  bad.  But  it 
ic  equally  as  devastating. " 

Interacting  with  colleagues  to  discuss  such 
topics  is  a  great  mechanism  for  building  our 
own  values  and  accumulating  'for  instances'  to 
relate  to  students.  We  had  a  faculty  dutch 
treat  lunch  recently  to  discuss  ethics.  1 
at  tended  a  breakfast  at  a  recent  professional 
meeting  devoted  to  this  topic.  Listening 
while  others  talk  about  touchy  issues  is  quite 
enlightening. 

If  there  were  a  file  cabinet  located  in  a 
hallway#  should  a  passerby  look  in?  If  there 
were  names  on  the  drawers,  would  he/eho  be 
more  or  less  likely  to  want  to  look  in?  If 
*.he  cabinet  were  locked#  would  he/she  feel 
challenged  to  look  in? 

Is  there  any  difference  in  walking  around  in 
Neiman “Marcus  at  2  a.  m.  and  walking  around  in 
someone's  database  at  2  a.m.  ?  If  caught# 
would  the  perpetrators  be  treated  differently? 
Should  they  be?  It  is  interesting  that  the 
Virginia  computer  crimes  legislation  includes 
a  statement  to  attest  that  a  "tangible  docu¬ 
ment  need  not  be  evident  when  a  computer  is 
the  instrument  of  forgery. •  Do  our  written 
laws  really  need  to  be  this  specific? 


GQNCLUS1UN 

Compute* &  arc  powerful  tools  at  the  disposal 
o.t  men.  Men  who  undei  stand  and  use  these 
machines  have  power  to  accomplish  groat  and 
vox  thy  goals  or  to  wreak  havoc:  and  destruc¬ 
tion.  Although  security  mechanisms  and  laws 
are  provided  to  temper  the  activities  of  men 
when  they  sit  down  at  the  machines#  the  only 
truly  binding  controls  are  the  professional 
ethics  ol  the  man. 
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There  are  many  diverse  opinions  on  the 
relative  importance  of  data  integrity  when 
compared  with  the  relative  importance  of  data 
secrecy.  In  the  Department  of  Defense 
Trusted  Computer  System  Evaluation  Criteria, 
integrity  is  defined  as  the  correct  operation 
of  the  hardware  and  firmware  upon  which  the 
operating  system's  Trusted  Computing  Base 
(TCB)  resides,  and  the  assurance  that  the  TCB 
software  has  not  been  subject  to  unauvhorized 
modification.  The  correct  operation  or  the 
TCB  only  ensures  that  the  file  system  is 
intact  and  that  the  TCB  has  not  been 
unintentionally  or  maliciously  modified.  The 
Criteria  makes  no  claim  as  to  the  validity  or 
consistency  of  the  information  that  may  be 
contained  in  the  files  protected  by  the  TCB. 

The  problems  of  data  integrity  have 
always  existed  in  trusted  operating  systems. 
Data  management  applications  of  these  systems 
make  the  problem  more  acute.  Consistent, 
accurate,  reliable  information  is  a  critical 
element  for  data  management  applications. 

This  paper  provides  an  overview  of  data 
integrity  concerns,  and  why  they  are  r^t 
sufficiently  addressed  by  conventional 
secrecy  policies.  The  issue  of  unauthorized 
modification  of  data  which  might  compromise 
data  validity  is  addressed,  as  is  the 
practicality  of  the  implementation  of  the 
current  state  of  the  art  in  integrity 
policies.  The  discussion  concludes  with  an 
attempt  to  provide  guidance  on  the 
application  of  integrity  policies  to  trusted 
data  management. 

THE  INTEGRITY  PROBLEM 

Before  the  industrial  Revolution,  most 
business  enterprises  were  established  by  and 
run  as  single  person  firms.  Data  integrity 
wan  not  a  consideration  because  every  piece 
of  information  required  to  run  the  business 
came  through  the  proprietor. 

Industrialization  brought  larger 
conglomerates  into  being.  It  was  not 
possible  to  run  a  nationwide  railroad,  for 
example,  with  one  bookkeeper  and  one 
accountant.  As  more  people  became  involved 
with  corporate  information,  data  integrity 
became  a  greater  problem.  Two-man  control  of 


sensitive  information  was  introduced  as  one 
control  methodology.  Single-point  access  to 
company  filerooms  was  another  way  tc  control 
access  to  corporate  information 
Information,  however,  was  becoming  more  and 
more  accessible  to  larger  numbers  of  people 
as  part  of  their  daily  duties.  However,  the 
amount  of  information  accessible  and 
chargeable  on  any  given  day  was  still 
relatively  limited. 

The  Computer  Age  increased  the  data 
integrity  problem  significantly.  More  data 
was  accessible  to  more  people  than  had  ever 
been  possible  with  manual  processing  methods. 
It  was  also  easier  than  ever  before  to  make 
wholesale  changes  to  information,  such  as 
cleaning  out  bank  accounts,  embezzling  funds, 
and  just,  simple  system  failures  wiping  out 
files.  Backup  copies  could  replace  lost 
files,  but  changes  were  harder  to  trace  to  a 
single  individual  and  restore.  Eventually, 
electronic  audit  files  were  used  to  establish 
a  chain  of  accountability  for  modifications. 
This  provided  a  way  to  know  who  last  accessed 
a  file  or  a  particular  account.  It  did  not 
offer  a  remedy  to  the  data  entry  clerk  wno 
mistyped  1.000  instead  of  1,000  and  forgot  to 
proofread  the  screen  before  pressing  the 
transmit  key. 

Database  management  systems  made  it  even 
easier  to  modify  large  quantities  of  data 
quickly  and  efficiently  with  simple  query 
languages.  These  systems  also  brought  new 
mechanisms,  such  as  data  dictionaries  and 
semantic  constraints,  into  common  use  as 
control  mechanisms  for  data  integrity  [8]. 

For  example,  it  was  now  possible  to  require 
only  numeric  data  for  social  security 
numbers,  and  social  security  numbers  had  to 
have  nine  digits.  When  such  mechanisms 
clashed  with  performance  requirements, 
however,  they  were  often  ignored  or 
circumvented,  leaving  information  more 
vulnerable  to  integrity  compromise. 

DEFINITIONS  OF  INTEGRITY 

This  brief  history  of  the  integrity 
problem  makes  it  easy  to  see  that  there  can 
be  many  definitions  of  data  integrity,  all  of 
which  are  valid.  Perhaps  an  integrated 
definition  of  integrity  can  be  found  in  [16]. 
This  definition  covets  six  areas: 
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a.  How  correct  we  think  the 
information  is, 

b.  How  confident  we  are  that  the 
information  is  from  its  original 
source, 

c.  How  correct  the  functioning  of 
the  process  is, 

d.  Kow  closely  the  process  function 
corresponds  to  its  designed 
intent, 

e.  How  confident  we  are  that  the 
information  in  an  object  is 
unaltered,  or  was  correctly  modified, 
and 

f.  How  correct  the  information  in  an 
object  is. 

How  correct  we  think  the  information  is 
can  be  considered  the  conventional  data 
management  definition  of  integrity.  in  the 
traditional  data  management  environment, 
integrity  is  defined  as  the  consistency  or 
validity  of  data  entered  into  a  database  or  a 
file.  This  definition  includes  semantic 
integrity  constraints  which  can  be  specified 
as  part  of  a  data  dictionary  or  application 
program,  such  as  all  salaries  must  be  greater 
than  zero;  concurrency  controls  which  ensure 
that  the  serializability  of  transactions  is 
maintained  to  prevent  interference  between 
two  or  more  executing  transactions;  and 
recovery  mechanisms  to  ensure  the  proper 
restoration  of  data  in  the  event  of  a  system 
failure . 

How  correct  the  functioning  of  a  process 
is,  and  how  closely  it  equates  to  its 
designed  intent  can  be  defined  as  operational 
consistency  and  correctness.  Operational 
consistency  equates  to  confidence  in 
achieving  the  same  results  if  the  same  code 
is  executed  repeatedly  with  the  same  input. 

It  is  the  ability  to  rely  on  system 
operations  and  services,  such  as  daemons,  to 
run  properly  with  predictable  results. 
Correctness  is  the  assurance  or  guarantee 
that  the  system  will  perform  as  its  designers 
intended  it  to  and  that  it  will  operate 
properly.  This  type  of  integrity  is  often 
referred  to  as  system  integrity. 

How  confident  we  are  that  the 
information  is  from  its  original  source,  has 
been  subjected  to  only  authorized 
modifications,  and  is  correctly  represented 
in  a  storage  object  can  be  considered  the 
computer  security  definition  of  integrity. 
This  definition  includes  the  mapping  of 
information  into  digital  data  for  storage  in 
an  object,  user  authentication, 
authorization  of  the  user  to  perform 
modifications,  and  confidence  that  the  user 
entered  error-free  information  into  the 
system  which  was  not  maliciously  cr 
unintentionally  altered  by  either  another 
user  or  the  operating  system. 

For  exampie,  a  user  enters  data  at  a 
terminal.  The  characters  are  translated  into 
asci:  code,  sent  '  an  i/o  buffer,  and 
eventually  stored  i  a  file.  The  user  is 
confident  that  th  characters  he  entered  were 
accurately  represented  and  not  altered  by  a 
short  circuit  into  a  different  bit.  pattern. 

He  may  wish  to  let  another  user  edit  this 
data  at  a  later  date,  and  sets  copy 
privileges  on  the  data  for  another  user. 

When  a  third  user  tries  to  copy  the  data,  he 


is  not  authorized  to  modify  it  and  is  denied 
access.  If  the  second  user  tries  to 
overwrite  the  data  he  is  not  permitted  to  do 
so,  because  it  would  be  an  unauthorized 
modification.  The  owner  of  the  data  also 
believes  that  the  operating  system  will  not 
lose  his  file  in  the  event  of  a  system  crash. 

WHY  WORRY  ABOUT  INTEGRITY? 

Is  a  trusted  computer  system  that 
enforces  a  global  security  policy  as 
described  in  the  Criteria,  sufficient  to  cope 
with  data  integrity  concerns?  In  the  Shirley 
and  Schell  paper  on  validation  by  assignment 
[20],  the  argument  is  made  that  a  security 
policy  is  based  on  external  laws,  rules, 
regulations,  and  other  mandates  that 
establish  what  access  to  data  is  permitted. 
Access  to  data  is  defined  as  what  information 
may  be  disclosed  to  any  given  user,  not  as 
what  information  may  be  modified  by  any  given 
user. 

However,  a  security  policy  that  addresses 
only  the  disclosure  of  information  is  not  a 
complete  policy.  In  Denning  and  Schell  [11], 
two  principal  components  of  ,the  information 
security  policy  are  proposed:  a  secrecy 
class  to  control  information  disclosure,  and 
an  integrity  class  to  control  the 
modification  of  information.  A  trusted 
system  is  trusted  to  protect  "sensitive" 
information  from  unauthorized  disclosure, 
alteration,  or  destruction.  Therefore,  a 
security  policy  that  addresses  only  secrecy 
is  not  sufficient  unless  it  also  addresses 
data  modification  issues,  or  data  integrity. 

There  are  precedents  and  true,  paper- 
based  procedures  upon  which  it  is  possible  to 
model  an  information  disclosure  policy. 
Landwehr  [15]  has  argued  that  a  similar  model 
for  an  integrity  policy  does  not  exist.  He 
states  that  the  government  possesses  large 
amounts  of  sensitive  information  that  would 
compromise  national  security  if  it  was 
revealed  to  certain  organizations  outside  of 
the  government.  Therefore,  it  has  had  to 
institutionalize  a  protection  policy  of 
hierarchical  classifications  and  compartments 
for  this  information.  No  damage  assessment 
of  the  consequences  of  unauthorized 
modification  of  such  information  has  resulted 
in  a  similar  set  of  hierarchical  integrity 
labels.  Therefore,  a  justification  for  a 
global  integrity  policy  to  protect:  against 
unauthorized  modification  of  sensitive  data 
does  not  currently  exist  in  government 
regulations.  On  an  application-specific 
basis,  information  that,  must  be  protected 
from  unauthorized  modification  car.  be 
identified  and  should  be  protected  using 
moans  appropriate  to  the  sensitivity  of  the 
information.  There  is  no  global  integrity 
policy  for  the  Federal  Government, 

Eeyond  these  arguments,  security 
policies  specified  by  the  Criteria  are 
required  to  have  mechanisms  available  to 
ensure  the  ."correct"  operation  cf  the 
software  and  firmware  comprising  the  TCS . 

The  Criteria  further  requires  that  assurances 
are  in  place  to  ensure  that  the  software  TCB 
is  subject  to  sound  configuration  management 
practices  and  distribution  techniques.  There 
is  no  requirement  in  the  Criteria  to  enforce 
data  consistency  constraints  or  other  such 
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common  integrity  measures.  Therefore,  a 
system  meeting  the  intent  of  the  Criteria 
does  not  guarantee  the  validity  of  the 
information  represented  within  its  objects. 

DOES  SECRECY  OFFER  SOLUTIONS? 

Can  integrity  concerns  be  addressed 
through  the  use  of  security  mechanisms 
designed  to  address  secrecy?  Secrecy 
concerns,  as  stated  above,  address 
information  dissemination,  not  information 
modification.  Integrity  is  often  considered 
the  dual  of  secrecy.  Using  a  secrecy  lattice 
for  integrity  enforcement,  therefore,  will 
protect  high-level  objects  from  low-level 
subjects,  but  equates  relative  integrity  with 
relative  secrecy.  hat  is,  the  most  widely 
disseminated  data  (unclassified  data)  would 
be  considered  the  least  vulnerable  to 
unauthorized  modification.  The  least  widely 
disseminated  data  (top  secret)  would  be  the 
most  vulnerable  to  unauthorized  modification 
because  it  would  be  the  most  enticing  to 
someone  trying  to  penetrate  the  system.  This 
is  a  restatement  of  the  secrecy  policy  for 
the  system. 

A  program  integrity  policy  [20]  will 
protect  against  insertion  of  malicious  code 
into  an  application  and  will  ensure  the 
enforcement  of  integrity  constraints  upon  a 
user's  application.  Such  a  policy  assumes 
that  the  development  staff  is  trusted.  The 
policy  will  not  enforce  an  access  control 
policy  by  itself,  and,  therefore,  cannot  be 
used  to  enforce  authorized  modification 
rules.  A  program  integrity  policy  does  not 
necessarily  have  access  control  lists 
associated  with  it  to  determine  which  users 
are  authorized  to  access  data  and  which  are 
not.  It  can  ensure  that  programs  behave 
"correctly",  but  cannot  ensure  against  data 
value  corruption  by  malicious  users. 

A  discretionary  integrity  policy  based  on 
access  control  lists  will  limit  the 
modification  rights  granted  to  a  user. 
However,  it  mattes  no  promises  about  the 
enforcement  of  integrity  constraints  or  the 
"correctness"  of  code.  A  discretionary 
integrity  policy  is  also  not  automatically  or 
uniformly  invoked  for  each  data  access  by 
every  user.  It  is  not,  therefore,  a 
mechanism  that  is  enforceable  with  a  high 
degree  of  assurance. 

THE  PROBLEM  OF  UNAUTHORIZED  MODIFICATION 

Various  extensions  and  alternatives  to 
the  current  generation  of  secrecy  policies 
have  been  developed  in  an  attempt  to  address 
integrity  considerations,  biba  [1]  discussed 
three  types  of  hierarchical  integrity 
policies:  (1)  strict  integrity,  (2)  ring 

policy  integrity,  and  (3)  low  water  mark 
integrity. 

The  strict  integrity  policy  considered 
integrity  the  dual  of  secrecy.  Whereas  the 
standard  Bell-LaPadula  security  policy 
permits  the  reading  down  and  writing  up  of 
information  in  secrecy  classes,  Biba  contends 
that  these  actions  compromise  the  integrity 
properties  of  the  data.  A  higher-secrecy- 
level  user  compromises  his  higher-secrecy- 
level  data  by  the  act  of  reading  data  at  a 
lower-secreoy-level .  A  lower-secrecy-level 


user  performing  a  blind  write  to  a  higher- 
secrecy-level  object  may  unintentionally  or 
maliciously  provide  misinformation  to  a 
higher-secrecv-level  process  that  wished  to 
use  the  same  data  file.  In  the  strict 
integrity  policy,  integrity  levels  are  used 
to  counter  this  threat.  A  user  may  read  an 
object  if  his  integrity  level  is  dominated  by 
the  object's  integrity  level.  A  user  may 
write  to  an  object  if  his  integrity  level 
dominates  the  object's  integrity  level. 

The  ring  policy  variant  on  Biba's  strict 
integrity  policy  states  that  no  restrictions 
are  placed  on  the  reading  of  data,  but  the 
constraints  on  writing  to  an  object  are  the 
constraints  specified  in  the  strict  integrity 
policy.  A  subject  may  write  high  integrity 
data  to  a  file  even  though  he  has  read  low 
integrity  data  in  the  same  process. 

The  object's  integrity  level  is  never 
changed  in  the  low  water  mark  integrity 
policy,  but  the  integrity  level  of  the 
subject  is  degraded  when  he  reads  data  at  a 
lower  integrity  level.  The  subject  may 
eventually  have  his  integrity  level  decreased 
to  the  lowest  integrity  level  on  the  system, 
the  low  water  mark.  To  restore  his  process 
to  a  higher  integrity  level  would  require 
reinitialization  of  his  privileges;  in  all 
probability,  this  would  require  a  trusted 
process . 

Denning  and  Schell  [11]  proposed  a  more 
flexible  variation  on  the  strict  integrity- 
policy.  This  integrity  policy  proposes  that 
trusted  subjects  can  read  objects  or  write  to 
them  as  long  as  they  fall  within  the 
permitted  range  of  integrity  levels. 

Untrusted  subjects  are  limited  to  reading  or 
writing  objects  as  stated  in  Biba's  strict 
integrity  policy.  An  additional  constraint 
is  added  by  the  execute  property,  which 
states  that  a  subject  can  execute  an  object 
only  if  the  maximum  integrity  level  of  the 
subject  is  less  than  or  equal  to  the 
integrity  class  of  the  object,  arid  the 
maximum  secrecy  level  of  the  subject  is 
greater  than  or  equal  to  the  secrecy  class  of 
the  object. 

The  variation  of  Biba's  strict  integrity 
policy  proposed  by  Shirley  and  Schell  [20] 
allows  the  reading  of  lower  integrity  level 
data  by  higher  integrity  level  processes. 
Execute  access  is  established  as  a  separate 
access  right,  and  a  process  may  only  execute 
processes  with  an  equal  or  greater  integrity 
level.  Write  access  rights  are  applied  as 
specified  in  Biba's  policy  model.  This 
affords  a  greater  degree  of  flexibility  than 
the  strict  integrity  model  because  read  and 
update  operations  could  be  performed  by  high- 
integrity  level  processes  across  all  lower- 
integrity  levels. 

Changeable  subject  integrity  levels  and 
program  integrity  levels  are  used  in  Boyun's 
[4]  variation  of  strict  integrity.  As  the 
user  reads  lower-integrity  data,  his 
integrity  level  is  downgraded.  This 
variation  also  introduces  the  notion  of 
programs  having  an  integrity  level  based  on 
their  potential  to  corrupt  higher-integrity 
data.  Since  they  offer  the  potential  for 
data  corruption,  programs  must  have  a  higher 
integrity  level  than  the  data  objects  they 
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will  be  acting  upon.  Unfortunately,  as  the 
user  reads  lower  and  lower  integrity  level 
data,  his  own  integrity  level  is  permanently 
degraded,  preventing  him  from  ever  reading 
high-integrity  data  again.  The  only  way  to 
restore  his  integrity  level  is  through  a 
trusted  upgrade  process,  executable  only  by  a 
trusted  subject,  as  in  the  low  water  mark 
policy. 

Another  type  of  integrity  policy  commonly 
used  in  commercial  applications  is  enforced 
strictly  through  rule-based  constraints. 

These  constraints  are  either  written  for  each 
application  separately  or  generalized  into  a 
global  integrity  policy  for  all  appli  •.ations 
of  a  particular  type.  For  example,  a  common 
set  of  type-checking  utilities  for  a  database 
management  system.  This  type  of  policy 
requires  a  trusted  process'  to  place  the  user- 
written  constraints  into  the  TCB.  Such  an 
expansion  of  the  TCB  would,  in  all 
probability,  make  it  larger  than  current 
analysis  techniques  could  handle,  which  would 
make  it  very  difficult  to  guarantee  the  level 
of  assurance  required  at  higher  levels  of  the 
Criteria. 

An  alternative  to  Biba's  strict  integrity 
policy  variations  was  proposed  by  Boebert  [?.] 
and  is  being  implemented  in  the  LOCK  project. 
This  policy  uses  the  concept  of  type-domain 
enforcement  to  implement  constraints. 

Objects  are  associated  with  types,  and 
subjects  are  associated  with  domains.  An 
access  matrix  of  domains  and  types  determines 
the  rights  available  to  a  subject  requesting 
access  to  an  object.  The  access  matrix 
consists  of  a  combination  of  static  access 
constraints  coupled  with  application-specific 
access  constraints  specified  by  a  trusted 
user.  If  a  domain  does  not  have  access  to  a 
given  type  as  specified  by  the  access  matrix, 
it  violates  the  integrity  policy  and  access 
is  not  permitted.  The  type-domain 
enforcement  integrity  policy  is  orthogonal  to 
the  secrecy  policy  and  is  logically  "andad" 
with  the  access  rights  granted  by  ohe  secrecy 
policy  to  determine  the  subject's  effective 
access  rights.  That  is,  the.  intersection  of 
the  two  matrices  form  the  access  privileges 
permitted  under  the  system  security  policy. 

ARE  THESE  POLICIES  USEFUL? 

Are  any  of  t.ne  various  integrity  policy 
alternatives  practical  in  a  operational 
environment?  or  is  the  current  generation  of 
integrity  policies  overly  protective? 

It  is  important  to  note  that  integrity 
policies  are  not  usually  implemented  by 
themselves.  They  are  usually  implemented  in 
conjunction  with  a  secrecy  policy  to  provide 
a  system  security  policy.  To  determine  the 
utility  of  an  integrity  policy,  its  position 
must  be  taken  into  consideration  with  respect 
to  the  overall  system  security  policy. 

Using  this  criteria,  the  strict  integrity 
interpretation  proposed  by  Biba  does  not 
appear  flexible  enough  to  be  useful  in 
practical  applications,  such  as  database 
management  systems  [2j.  Applications  must 
have  read  and  write  access  to  various  system 
tables  and  internal  data  structures  in  order 
to  perform  their  functions.  in  the  context 
of  Biba's  strict  integrity  policy,  this  can 
only  be  accomplished  if.  the  integrity  level 


of  all  relevant  data  is  system  low.  However, 
a  system  low  integrity  level  affords  this 
data  minimal  protection  under  t.ha  integrity 
policy . 

The  ring  integrity  policy  uses  fixed 
integrity  labels  on  both  subjects  and 
objects.  It  allows  the  subject,  however,  to 
read  data  at  any  integrity  level  and  write  to 
objects  of  lesser  or  equal  integrity  levels. 
No  execute  access  is  defined  in  this  policy. 
Therefore,  the  subject  integrity  level  is  of 
little,  value  since  programs  of  dubious 
integrity  may  be  executed  by  a  subject  with  a 
high  integrity  level.  Such  a  practice  would 
allow  the  destruction  of  any  higher-integrity 
data  which  the  subject  may  access.  This 
policy  has  never  been  implemented  in 
practice . 

The  low  water  mark  policy  allows  a 
subject  to  paralyze  itself.  While  necessary 
objects  can  be  created  at  higher-  integrity 
levels  and  the  subject  can  access  them  as 
long  as  it  maintains  an  equal-integrity 
level,  reading  a  lower-integrity  object  will 
degrade  the  integrity  level  of  the  subject, 
making  tne  higher-integrity  objects 
inaccessible  to  the  now  lower-  integrity 
subject. 

Denning  and  Schell's  integrity  range, 
Shirley  and  Schell's  program  integrity 
policy,  and  Boyun's  changeable  integrity 
policies  all  are  attempts  to  incorporate  more 
flexibility  into  the  strict  integrity  policy. 
Whether  the  increased  flexibility  they 
provide  will  also  increase  the  size  of  the 
TCB  bevond  analytical  limits,  degrade 
performan  s,  or  create  new  integrity  concerns 
ar.d  security  covert  channels  has  yet  to  be 
investigated. 

A  rule-based  integrity  policy  is  not,  in 
and  of  itself,  applicable  to  the  general 
case.  Rules  charge  from  one  application  to 
another,  and  one  "sor  interface' to  another. 
Additionally,  such  a  rule-based  integrity 
policy  may  provide  a  substantial  inference 
channel  if  simultaneously  enfnroud  at 
multiple  secrecy  levels  with  a  single 
instantiation  of  the  data.  A  user  at  a  given 
level  may  be  able  to  carefully  construct 
queries  that  would  allow  nip  to  determine  the 
information  he  was  not  permitted  to  access. 

The  type-domain  enforcement  mechanism 
proposed  by  Boebert  may  prove  useful  when  the 
number  of  enumerated  types  enforced  is 
relatively  small.  However,  user-specified 
typss  may  be  more  numerous  arid  could  possible 
cause  serious  performance  penalties,  unless 
matrix  compression  techniques  were  used  on 
the  access  matrix.  More  investigation  must 
ba  conducted  to  determine  the  properties 
associated  with  type-domain  enforcement 
mechanisms . 

OTHER  INTEGRITY  CONSIDERATIONS 

Poly instantiation  [11]  has  been  proposed 
as  one  solution  to  the  integrity— secrecy 
dilemma.  If  a  higher  secrecy  cr  integrity 
user  attempts  to  perform  a  modification 
operation  on  lower  level  data,  another  copy 
of  the  data  is  automatically  created  that  is 
identical  to  the  original  in  all  but  the 
level  designation.  This  higher-level 
instantiation  of  the  data  then  reflects  the 
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higher -level  us.ar's  modifications.  While  it 
will  ensure  that  the  security  policy  is  not 
violated,  polvrnstantiation  will  not  solve 
the  problems  of  data  consistency.  Data  that 
is  replicated  at  each  level  will  guarantee 
consistency  within  one  level,  but  will  not 
ensure  consistency  across  levels.  The  entire 
database  would  not  necessarily  be  consistent. 
In  this  case,  one  can  never  be  certain  v/hich 
instantiation  of  the  original  data  is  the 
most  accurate  or  recent  representation. 

As  a  final  consideration,  one  must 
examine  the  user  interface  issues  entailed  by 
the  various  policies.  If  the  user  is  only 
permitted  to  read  or  write  at  a  single  level, 
mechanical  cut-and-paste  techniques  will  be 
required  to  obtain  all  of  his  data  in  a 
single  report.  Users  in  general  may  be  able 
to  adjust  to  almost  anything,  provided  they 
do  not  „  ^roeive  duplication  of  effort.  When 
update  operations  become  excessively  tedious, 
as  may  be  the  case  with  the  strict  integrity 
policy,  users  become  increasingly  rebellious 
and  either  cease  to  use  the  syst«R  or  develop 
their  own  integrity  policy:  the  high  water 
mark.  No  one  piece  of  the  integrity  puzzle 
fits  all  the  empty  places  in  a  security 
policy. 

CAN  HIGH  DATA  INTEGRITY  EXIST  WITH  HIGH 
TRUST? 

Data  integrity  cannot  be  ignored  in  a 
trusted  computer  system.  Assurance  that  the 
TCB  is  functioning  correctly  at  the  operating 
system  level  is  not  enough  for  trusted 
applications  that  require  data  to  be  valid 
and  consistent.  No  one  data  integrity  policy 
clearly  satisfies  the  many  varieties  of 
integrity  considerations.  Environmental 
factors  must  also  be  taken  into 
consideration.  Just  as  the  various 
evaluation  classes  of  the  Criteria  do  not 
unilaterally  apply  to  all  cases,  neither  can 
integrity  policies  be  blindly  applied  without 
consideration  of  the  sources,  frequency  of 
modification,  sensitivity,  and  perishability 
of  data. 

A  layered  approach  to  data  integrity  may 
be  the  best  near-term  solution.  In  such  an 
approach,  the  underlying  support  features  of 
the  operating  system’s  TCB  would  be  used  to 
the  most  feasible  extent,  and  the  application 
would  be  responsible  for  additional 
assurances . 


based  on  operating  system  architectural 
features  that  are  nonexistent.  Additionally, 
the  integrity  policy  in  effect  must  minimize 
any  extensions  to  the  TCB  boundary  that  may 
be  required  for  its  support.  Variations  cn 
Elba's  strict  integrity  policy  may  be  more 
appropriate  here. 

Can  a  high  degree  of  data  integrity 
coexist  with  a  high  degree  of  trust?  The 
current  generation  of  highly  trusted 
operating  systems  have  not  been  conclusively 
examined  in  this  area.  Attempts  to  build 
high  integrity  data  management  applications 
on  Honeywell's  Multics  system  severely 
limited  the  user's  ability  to  exercise 
untrusted  applications  and  other  system 
features.  Perhaps  if  a  trusted  system  were 
dedicated  to  a  specific  application,  in 
execute-only  mode,  high  data  integrity  could 
coexist  with  highly  secure  operating  systems. 

CONCLUSIONS 

In  conclusion,  there  have  been  many 
different  integrity  policies  proposed.  Few 
of  them  nave  been  tested  through  a  system 
implementation,  still  fewer  have  actually 
proven  successful  in  operational 
environments.  Each  application  must  be 
examined  or.  an  individual  basis  to  determine 
which  integrity  policy  best  fits  its 
requirements  or  if  a  combination  of  integrity 
policies  is  more  appropriate. 
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ABSTRACT 

The  National  computer  Security  Center 
is  developing  a  document  containing  inter¬ 
pretations  of  the  Department  of  Defense 
T misted  Computer  System  Evaluation  criteria 
(TCSEC)  for  database  management  systems. 
With  each  interpreted  TCSEC  requirement,  a 
rationale  for  the  interpretation  is  stated. 
These  sections  of  the  document  will  be 
supported  by  appendices  that  address 
security  issues  that  are  unique  to  database 
management  systems.  The  document  will  be 
entitled,  "Trusted  DBMS  Interpretations", 
(TDI) . 


NCSC  COMMITMENT  TO  DBMS  SECURITY 

A  majority  of  data  processing  installs- 

ignite  noa  dntjbiES 

systems.  With  the  expanding  information 
age,  the  percentage  of  installations  doing 
data  base  management  is  increasing  signifi¬ 
cantly.  Unfortunately,  the  presence  of  a 
trusted  operating  system  in  these  installa¬ 
tions  does  not  guarantee  that  the  DBMS  can 
be  used  to  share  information  in  a  trusted 
manner . 

There  are  several  characteristics  that 
are  common  to  most  DBMS's  which  make  it 
necessary  for  them  to  provide  some  credible 
security  controls.  In  many  operational 
environments,  users  interface  directly  to 
the  DBMS,  which  makes  the  operating  system 
appear  transparent.  In  fact,  D3MS  designers 
often  choose  not  tc  utilize  the  services 
provided  by  operating  systems,  including  the 
security  features.  In  addition,  DBMS's 
typically  provide  the  capability  to  share 
objects  that  are  of  a  more  abstract  type 
than  operating  systems  are  capable  of 
recognizing.  These  characteristics,  among 
others,  create  the  need  for  security 
controls  within  the  DBMS  to  control  access 
to  these  objects. 

Based  upon  these  facts,  the  NCSC  is 
committed  to  determining  the  extent  to  which 
database  management  systems  can  be  trusted 
to  control  sharing  of  sensitive  data,  and  to 
evaluating  and  rating  commercially  available 
systems  against  a  practical  and  reasonable 
criteria. 

This  commitment  will  be  realised 
through  the  TDI  that  ia  now  being  developed. 
The  TDI  will  strive  to  specify  achievable, 
practical  requirements  in  order  to  allow 
current  DBMS  installations  to  become  more 
secure,  while  laying  the  framework  for 


technologically  advanced  trusted  database 
management  systems  in  the  future. 


HIST-QBY  -AND-STATU.S  .OF  TDI  .DEVELOPMENT 


NCSC  Effort.  Begins  -  Spring  1985 

In  May  of  1985  the  NCSC  began  to 
examine  requirements  for  multilevel  data 
management  in  an  effort  to  determine  whether 
or  not  guidance  should  be  written  on  the 
subject.  It  was  also  part  of  the  task  to 
determine  what  the  scope  of  such  guidance 
should  be.  That  is,  we  had  to  identify  what 
audience  cculd  benefit  the  most  from  a 
document  on  DBMS  security.  We  identified 
three  basic  audience  segments  that  could 
potentially  use  guidance  to  be  DEMS  userE, 
DBMS  builders,  and  DBMS  evaluators.  Users 
would  benefit  most  immediately  from  a 
document  that  provided  suggestive  guidance 
on  how  to  configure  and  use  existing  systems 
in  a  secure  manner.  DBMS  builders  would 
need  a  document  that  provided  TCSEC  type 
criteria  on  what  security  features  a 
database  management  system  should  have. 

Of  course  the  later  document  would  also 
indirectly  help  users  to  improve  the 
security  poBture  of  their  DBMS  installations 
over  the  long  run,  by  encouraging  the 
development  and  evaluation  of  trusted 
database  management  systems.  We  recognized 
that  this  is  clearly  the  most  desirable  type 
of  DBMS  security  guideline  to  be  produced  by 
NCSC.  We  were  then  faced  with  the  task  of 
determining  if  it  was  technically  feasible 
to  develop  trusted  database  management 
systems,  which  would  determine  the  practi¬ 
cality  of  a  criteria  type  guideline. 


DBMS  Security  Workshop  -  June  1986 


To  determine  current  technology's 
ability  to  support  a  DBMS  security  criteria, 
we  organized  a  workshop  to  discuss  the  state 
of  the  art  in  database  management  system 
security.  The  workshop  was  held  in  Balti¬ 
more  during  June  of  1986  and  was  attended  by 
57  experts  from  DBMS  vendors  and  their 
customers,  government  and  academia.  The 
participants  were  divided  into  three  working 
groups  chsrged  respectively  with  producing 
reports  on  security  policy,  data  integrity 
and  inference,  and  trusted  DEMS  architec¬ 
tures.  Each  report  details  the  technologi- 
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cally  possible  solutions  in  each  of  these 
areas  as  well  as  the  problems  that  require 
further  research  and  development.  These 
reports  and  all  issue  papers  written  in 
preparation  for  the  Workshop  are  available 
in  [CSC86] . 


Develop  Preliminary  Drafts  -  December  1986 

At  the  beginning  of  FY8'  NCSC  tasked 
Mitre  and  Aerospace  to  develop  preliminary 
drafts  of  DBMS  evaluation  criteria.  The 
drafts  were  to  be  in  the  form  of  interpre¬ 
tations  of  the  TCSEC  for  database  management 
systems.  This  approach  was  chosen  based 
upon  the  belief  that  the  TCSEC  contains  all 
of  the  fundamental  requirements  and  control 
objectives  that  are  necessary  for  any 
trusted  computer  system.  In  the  case  of 
database  management  systems,  as  well  as 
networks,  the  fundamental  requirements  need 
to  be  interpreted  more  specifically  for  that 
type  of  system. 

The  preliminary  drafts  were  delivered 
to  NCSC  on  31  December  1986.  They  were  used 
as  a  baseline  to  produce  the  working  draft 
of  the  TDI . 


Working  group  Formed  to  Refine  Draft  - 


NCSC  selected  a  working  group  to  steer 
the  refinement  cf  the  preliminary  drafts 
into  a  releasable  draft.  The  working 
group's  goal  is  to  produce  a  releasable 
draft  by  late  1987.  The  group  decided  at 
the  first  meeting  to  work  toward  a  DBMS 
document  that  mirrors  the  TCSEC  in  the 
number  of  evaluation  classes  it  contains  and 
in  the  degree  of  security  represented  by 
each  claBS. 

While  the  general  feeling  is  that  the 
evaluation  classes  in  the  TDI  should  be 
roughly  equivalent  in  features  and  assuran¬ 
ces  to  the  respective  classes  in  the  TCSEC, 
the  group  did  recognize  that  some  require¬ 
ments  which  are  unique  to  a  DBMS  environment 
will  have  to  be  added  (e.g.,  prevention  of 
unauthorized  data  modification) .  The  group 
quickly  reached  a  consensus  that  the 
requirements  must  be  practical  and  achieva¬ 
ble  with  current  technology. 

The  TDI  will  contain  appendices  that 
address  issues  requiring  further  explanation 
than  can  be  reasonably  provided  in  the  main 
body  of  the  document.  Appendices  will 
address  issues  concerned  with  system 
architecture,  including  the  implications  of 
using  multiple  hardware  bases  (e.g., 
database  machines)  and  the  distribution  of 
security  functionalities  over  distinct 
subsets  of  the  system  TCB.  Additionally, 
there  will  be  an  appendix  that  addresses 
database  integrity  and  consistency. 

The  group  did  net  attempt  to  specify 
requirements  for  areas  that  are  on  the 
research  fringes  of  DBMS  and  computer 
security  technology.  Problems  that  are 
considered  to  be  intractable  will  be 
identified  and  referred  to  the  research  and 
development  office  of  the  NCSC.  Through 


worked  examples  of  trusted  database  manage¬ 
ment  systems,  research  and  development  will 
be  able  to  prove  whether  or  not  pragmatic 
solutions  to  these  problems  exist. 

It  is  expected  that  research  in  the 
area  of  DBMS  security  will  progress  enough 
over  the  next  five  years  to  enable  the 
resolution  of  today's  research  problems,  if 
this  happens  the  TDI  will  evolve  to  encom¬ 
pass  the  newer  technology. 


SECURITY  AT  THE  SYSTEM  TJ!V7!]T. 

The  most  reliable  place  to  implement 
security  controls  on  any  type  of  computer 
system  is  at  the  system  level.  The  security 
controls  are  much  more  robust  when  they  are 
implemented  close  to  the  physical  represen¬ 
tation  of  the  information  to  be  protected. 
Thus  we  must  require  that  the  system 
implement  as  many  of  the  security  controls 
as  is  technologically  feasible  to  achieve 
the  greatest  level  of  security. 

The  main  body  of  the  TDI  will  specify 
requirements  that  DBMS  vendors  provide 
security  mechanisms  to  control  the  sharing 
of  databases.  The  TDI  will  not  enable  the 
evaluation  of  database  management  systems  in 
isolation.  Instead,  it  will  require  that 
they  be  evaluated  in  the  context  of  their 
supporting  operating  system  and  hardware 
base.  Thus  the  evaluation  will  be  of 
specifically  configured  systems,  which  are 
the  most  robust  way  to  ensure  that  the 
various  security  mechanisms  work  together 
properly. 


TCB  SUBSETS  AND  INCREMENTAL  EVALUATION 

A  relatively  new  concept  addressed  in 
the  TDI  is  that  of  TCB  subsets.  TCB  subsets 
occur  when  the  DBMS  reiies  upon  the  operat¬ 
ing  system  to  provide  it  with  a  portion  of 
the  overall  system's  security  features  end 
assurances.  The  TDI  will  specify  prescrip¬ 
tive  requirements  for  how  TCB  subsets  must 
interface  and  function  as  a  complete 
security  system.  An  in-depth  discussion  of 
this  concept  will  be  provided  in  an  appendix 
to  the  document. 

The  precise  way  in  which  the  TCB 
subsets  must  interface  is  that,  they  must  be 
implemented  in  layers,  where  the  security 
policy  of  a  lower  level  subset  is  used  by 
all  higher  level  subsets.  The  higher  level 
subsets  can  never  bypass  the  security  policy 
of  the  lower  levels,  but  they  may  add  their 
own  security  policy  that  does  not  conflict 
with  the  policy  of  the  lower  levels. 

If  TCB  subsets  interface  in  a  precisely 
defined  way,  an  evaluation  methodology  that 
will  bocome  known  as  incremental  evaluation 
will  be  used  to  evaluate  the  DBMS.  This 
will  be  possible  when  a  DBMS  is  undergoing 
an  evaluation  in  the  context  of  an  operating 
system  that  has  been  previously  evaluated, 
or  is  being  evaluated  at  the  same  time.  If 
the  DBMS  uses  the  security  policy  of  the 
underlying  operating  system,  and  is  layered 
properly  on  top  of  the  operating  system, 
then  this  system  is  a  candidate  for  an 
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incremental  evaluation  that  can  be  done  in 
two  increments.  The  results  of  the  operat¬ 
ing  system's  evaluation  can  be  used  as  input 
to  the  evaluation  of  the  operating  eystem- 
DEMS  combination.  Note  that  in  the  event 
that  the  DBMS  bypasses  any  operating  system 
services  that  were  included  in  the  previous 
evaluation,  the  incremental  evaluation 
methodology  cannot  be  used,  as  the  base  TCB 
subset  has  been  altered. 

The  rating  resulting  from  the  incremen¬ 
tal  evaluation  would  apply  only  t.o  the 
aggre<~  ate  of  the  TCB  subsets  when  used 
toget  >r.  It  would  not  apply  to  the  DBMS 
TCB  <  _oset  if  it  were  ported  to  another 
operating  system.  The  rating  of  the  overall 
TCB  must  always  be  less  than  or  equal  to  the 
ratings  of  all  of  the  previous  increments  in 
the  evaluation.  That  is,  adding  a  TCB 
subset  cannot  improve  the  rating  of  the  base 
TCB. 

If  the  additional  DBMS  TCB  does  not 
interface  correctly  with  the  base  TCB,  the 
incremental  evaluation  methodology  cannot  be 
used.  For  example,  performance  considera¬ 
tions  might  dictate  that  the  DBMS  be 
designed  to  bypass  some  of  the  operating 
systeu'e  services.  In  this  case,  the  entire 
system  must  be  reevaluated  in  its  entirety, 
because  the  TCB  that  was  present  in  the 
operating  system  is  not  being  used  by  the 
DBMS.  This  type  of  evaluation  methodology 
is  directly  analogous  to  a  traditional 
operating  system  evaluation.  Since  the 
original  operating  system  rating  iB  Invalid, 
it  is  possible  that  the  DBMS  evaluation 
could  result  in  a  higher  rating  than  the 
operating  system  had  received. 


EXPLICIT  REQUIREMENTS  FOR  INTEGRITY 

The  TDI  will  place  significantly  more 
emphasis  on  integrity  of  the  protected  data 
than  the  TCSEC  does.  The  concept  of 
integrity  is  divided  into  two  fundamental 
areas:  unauthorized  modification  of  the 


data,  and  consistency  and  correctness  of  the 
database.  The  requirements  for  unauthorized 
modification  will  be  integrated  into  the 
security  policy  of  the  system.  Separate 
requirements  might  be  written  to  ensure  that 
the  DBMS  contains  features  to  ensure  the 
consistency  and  correctness  of  the  database. 
However,  as  of  this  writing,  this  area  is 
less  understood,  and  it  ie  questionable  as 
r.o  what  level  of  assurance  we  can  get  that 
consistency  and  correctness  controls  are 
correct.  As  a  matter  of  fact,  there  is  not 
unanimous  agreement  that  consistency  and 
correctness  requirements  belong  in  the  TDI, 
as  some  view  them  as  DBMS  operational 
requirements  as  opposed  to  DBMS  security 
requirements. 


Credit  for  many  of  the  ideas  in  this 
paper  is  due  to  the  members  of  the  Trusted 
DBMS  Interpretations  Working  Group:  Dr.  D. 
Elliott  Bell,  Dr.  John  Campbell,  Dr.  Deborah 
Downs,  Kenneth  Eggers,  Richard  Graubart, 

Neal  Haley,  Ronda  Henning,  Terry  Mayfield, 
Dr.  Robert  Morris,  Dr.  Soger  R.  Schell,  Dr. 
T.C.  Ting,  Mario  Tinto,  and  Grant  Wagner.  I 
express  my  appreciation  for  the  ideas  and 
insights  that  these  people  have  given  to  the 
Center's  efforts  in  DBMS  security. 
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Insider  Threat  Identification  Systems 
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Abst  net. 

Motivation  is  cstablislird  for  tin*  importance*  of  addressing 
the  risks  arising  from  insider  threat  tin  automated  information 
systems.  The  insider  threat  is  eliaraeteri/ed  and  tin*  types  of 
damage  to  the  system  sponsor  are  outlined.  The  concept  of  an 
insider  t (treat  identification  system  is  introduced  as  a  framework 
and  a  discipline  for  addressing  this  threat.  The  basic  compo¬ 
nents  of  such  a  system  are  outlined.  Mandatory,  internal  sys¬ 
tem  surveillance  is  identified  as  the  foundation  component  <»t 
an  insider  threat  identification  system.  Us  characteristics  are 
discussed  and  the  current  status  of  surveillance  technology  is 
noted.  The  second  component  is  a  capability  for  analyzing  the 
data  captured  by  system  surveillance.  The  work  done  in  this 
field  is  reviewed.  An  expert  system  for  analysis  of  a  surveillance 
knowledge  base  to  identify  suspicious  events  is  proposed.  T  he 
last  three  components  of  an  insider  threat,  identification  sys 
tern  are  outlined.  'Their  dependence  on  a  keystroke  and  system 
response  level  of  surveillance  is  noted.  However,  discussion  of 
these  components,  dealing  with  investigative  evidence  gather¬ 
ing,  damage  assessment  and  recovery  support,  arc  outside  the 
scope  of  this  paper.  This  work  has  been  privately  funded  in  tiie 
interest  of  product  and  market  development. 

1.  Introduction 

It  is  widely  recognized  among  the  many  critically  concerned 
professionals  and  policy  makers  in  the  Infoscc  community  that 
managing  the  risks  arising  from  insiders  on  sensitive  computer 
systems  is  of  major  and  growing  importance.1  An  insider  may 
he  characterized  as  a  member  of  a  population  of  trusted  users  for 

1  A  number  of  policy  makers  and  professionals  have  gone  «ui  record  about 
these  emu  crus  and  *  lie  importance  of  managing  the  risk  from  insider  threat. 
The  following  are  excerpts  from  some  open  letters  to  the  author:  “We  ap 
preciatr  your  effort  in  addressing  new  technologies  on  the  insider  threat 
against  sensitive  computer  systems  We  are  also  pleaded  to  note  that  you 
are  working  closely  with  the  National  Computer  Security  Center  and  its 
new  Chief  Scientist  in  this  regard. .  . .  Wc  encourage  you  t«>  continue  your 
valuable  work  to  provide  computer  security  products,  especially  those  de¬ 
signed  to  specifically  counter  the  insider  threat,  . . —  Ponuld  C.  Latham, 
Assistant  Secretary  of  Defense  (C.I),  January  2.  1987  “It  is  inv  firmly  held 
opinion  that  a  substantial  majority  of  financial  losses  sufferer!  in  the  private 
sector  are  caused  by  insiders.  ...  In  most  cases,  the  acts  that  have  caused 
the  losses  have  been  done  by  pe-sons  who  had  the  authority  to  perform 
the  acts.  .  .  .  Any  contribution  U  Tie  interpretation  of  audit  information 
(computerized  or  otherwise)  to  counter  these  threats  would  clearly  advance 
the  interests  of  computer  security,”  —  Dr.  Robert  Morris,  Chief  Scientist, 
Notional  Computer  Security  Center,  November  20,  1986.  “I  sincerely  ap¬ 
preciate  your  bringing  these  [insider  threat]  concerns  to  my  attention  and 
yout  continuing  interest  in  developing  technologies  to  counter  the  insider 
threat...  .  ” — Harold  K  Daniels,  Deputy  Director  for  Information  Security, 
National  Security  Agency,  May  1,  1987.  [.ale  in  November,  1986,  the  Asso 
ciated  Press  reported  that  the  President  had  sent  an  anti  spy  master  plan 
to  the  House  and  Senate  intelligence  committees.  This  news  item  staled  in 
part:  “The  president’s  plan  is  an  unprecedented  blueprint  for  broad  based 
reform  to  U-S  efforts  to  count  the  Soviet  bloc  intelligence  threat.  . .  The 
Defense  Department  is  direct-  1 .  .  .  to  provide  monetary  or  administrative 
penalties  for  contractors  with  security  lapses  and  bonuses  for  those  with 
tight  programs.  .  .  .  Additional  research  is  promised  on  technical  safeguards 
for  secrets  stored  in  computers . .  .  sooner  or  later  we’l!  come  across  a  spy 
case  involving  computer  thelt  of  sec  rets.” 


a  given  installation;  that  is,  an  insider  has  authorized  access  to 
the  automated  information  system  and  the  resource  it  inanages. 
Access  limits  for  each  insider  are  set  by  security  policy  and 
enforced  l>v  the  computer  access  controls.  Tin-  degree  of  trust 
placed  in  a  given  insider  may  vary  from  one  site  population  to 
another,  and  it  may  also  vary  within  a  population.  I  he  degree 
of  trust  assigned  to  each  insider  is  gem-rally  a  eouseipieuee  of  a 
formal  review  or  investigation  ot  the  person  s  background  and 
integrity. 

Inappropriate  conduct  of  an  insider  in  the  use  of  an  an 
touiatod  information  system  constitutes  a  threat  of  potential 
damage  to  the  sponsor  of  the  system,  i  his  conduct  may  be 
characterized  as  any  use  of  the  system  that  violates  actual  or 
intended  policy.  Unauthorized  persons  who  by  skill  may  pene¬ 
trate  the  access  controls  of  the  system  are  regarded  as  intruders. 
Such  persons  have  the  same  potential  for  damage  to  the  spun 
sor  as  does  the  inappropriate  conduct  of  insiders.  Where  such 
insiders  may  also  seek  to  extend  the  boundaries  of  their  autho¬ 
rization,  the  distinction  between  these  insiders  and  intruders 
is  not  important  relative  to  the  technologies  required  for  the 
protection  of  the  sponsor.  The  sponsor  may  he  an  agency  of 
the  government,  a  military  group,  a  government  contractor,  a 
national  laboratory,  or  an  entity  in  the  private  sector. 

Damage  to  the  sponsor  may  take  a  number  of  forms.  Much 
has  been  reported,  and  the  following  is  a  distillation  of  the  basic 
categories:2 

Denial  of  Service:  The  system  becomes  inoperable, 
unresponsive  or  corrupted  in  some  manner.  Some  or 
all  of  the  users  are  unable  to  perform  their  tasks  on 
the  system  in  a  .normal  way. 

Information  Loss:  Information  managed  by  the  sys¬ 
tem  is  lost  by  destruction  or  corruption. 

Disinformation:  Information  is  altered  in  a  manner 
that  misleads. 

Information  Compromise:  Information  is  conveyed 
to  persons  not  authorized  by  policy  to  receive  it. 

Resource  Exploitation:  The  system  is  used  to  pro 
mote  objectives  within  or  outside  of  the  system  that 
are  not  authorized  by  policy. 

Damaging  conduct  in  the  use  of  automated  information 
systems  may  he  a  consequence  of  ignorance,  error  or  malfea¬ 
sance.3  This  paper  addresses  the  identification  of  insider  threat 
arising  from  any  conduct  that  damages  the  sponsor  by  violating 
actual  or  intrnded  policy.  The  objectives  of  such  a  system  in¬ 
clude  the  identification  of  the  perpetrator  and  assessment  of  the 
damage,  together  with  support  procedures  for  recovery.  These 
objectives  depend  on  the  successful  collection  and  analysis  of 
detailed  surveillance  data.  When  these  objectives  are  served, 
it  is  also  possible  to  take  corrective  measures  that  increase  the 

7  This  categorization  of  damage  lias  hern  distilled  from  a  wide  range 
of  recent  publications  discussing  and  reporting  computer  crime,  including 
technical  journals,  trade  magazines  and  the  public  media.  These  summarized 
categories  appear  to  include  the  various  forms  of  damage  being  currently 
reported  by  the  sponsors  of  automated  information  systems. 

3  From  the  information  reported  in  the  press,  the  spy  case  involving 
Jonathan  J.  Pollard  included  the  theft  and  compromise  of  large  volumes 
of  information  managed  by  a  secure,  automated  information  system  at  a 
military  site  This  site  was  protected  by  computer  access  controls  supplied 
by  a  major  government  vendor  These  widely  used  access  controls  were  not 
effective  against  insider  threat.  Similarly,  such  access  control  also  fails  to 
offer  protection  to  the  sponsor  from  the  damaging  potential  consequences  of 
ongoing  training  inadequacies  and  human  error. 
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K-sisfani'c  of  the  system  to  the  kind  *if  threat  cnmiinUTrrl.  Se¬ 
curity  policy  can  thus  he  up  laicil,  and  the  ad  minis! ration  of 
access  cdii'.rnls  can  Mib-aquoruiy  lu-  improved. 

Dr.ni.-^c  ii»  the  sponsor  tiny  tu-'ur  cntiicly  within  flu* 
liaiiicwni  k  ol  authorized  access  to  the  various  objects  protected 
within  an  autninaied  information  system.  Kxamplrs  <.f  such  «il> 
jecls  ate  files,  programs  und  memory  structures.  It  is  clear  that 
the  access  controls  of  a  trusted  computing  system  will  not  pro 
vide  protection  under  these  einuiiistaiue:-.  However*  insidns 
perpetrating  damaging  activity  ace  being  detected  at  a  number 
of  sites  with  user-iiUerat  tion  siu\ eillance  technology. 1 

Compromise  and  exploitation  may  also  occur  through  a 
penetration  of  access  emit  p»is  a  ud  an  exp  insioii  of  access  hound 
arief»  by  skilled  insiders.  Instructions  on  how  to  penetrate  the 
secure,  general  purpose  computer  systems  now  in  witle  use  may 
often  he  found  mi  the  college  campus  and  in  the  university 
library.5  There  are  only  a  few  systems  that  have  been,  «»r  soon 
will  be,  rated  by  the  National  Computer  Security  Center  as 
having  access  controls  that  are  trusted  at  the  high  end.  that 
is,  at  the  Al  level  of  security.**  I  he  trusted  systems  now  in 
dominant  use  have  ratings  at  the  Cl  and  C2  levels  and  are  not 
very*  tamper- resistant..  For  example,  trojan  horse  attacks  and 
the  insertion  of  viruses  and  worms  continue  to  be  quite  suc¬ 
cessful  (18].  Kvcn  should  access  control  technologies,  together 
with  their  availability  and  cost,  meet  the  community's  highest 
expectations,  technologies  that  identify  insider  threat  remain  a 
complementary  and  essential  part  of  computer  security. 

Where  many  of  the  critical  systems  of  interest  are  phys¬ 
ically  secured  within  vault  type  bmlwiiigs,  it  is  clo<ti  tluu  the 
management  of  risk  arising  from  insiders  is  of  dominant  im¬ 
portance  in  protecting  sensitive,  automated  information  from 
compromise  and  exploitation.  Historically,  the  management  of 
this  risk  has  been  sought  by  physical  security,  computer  ac¬ 
cess  controls,  and  a  suitable  clearance  f«»r  the  graming  *.-f  tru.,t 
to  users.  However,  as  evidenced  by  the  Jonathan  J.  Pollard 
case  and  similar  cases,  technology'  that  identifies  insider  threat 
needs  to  address  the  problem  of  altered  motivations  in  popula¬ 
tions  of  trusted  users.  Trie  same  technology  can  also  address 

*  A  .minher  of  cases  have  been  fepo.ued  to  the  vendor  of  the  Sent r y- 
GATI-  product  Concerning  the  deter l  i«»»i.  evidence  gathering  and  termination 
of  damaging  activities  hv  insiders  on  secure  systems  through  the  deployment 
of  surveillance  technology.  The  access  controls  supported  ny  ,i  trusiru  com 
pitting  base  are  not  intended  to  address  die  detection  of  nsichr  threat,  out 
rather,  the  prevention  of  Annul  hmized  access  1 ) '.  Case  sludir.*,  of  perpeura 
tor  identification,  evidence  gathering,  damage  assessment  and  recovery  no* 
in  preparation  «it  a  number  of  sites 

5  It  has  been  the  habit  of  the  vendor*  of  the  most  v/idelv  used  secure 
systems  to  publish  lists  and  descriptions  of  problems  fixed  in  new  versions  of 
these  operating  systems,  where  such  systems  either  contain  or  support  the 
trusted  computing  base.  Ihcsc  systems  include  MVS,  VMS  am!  UNiX.  This 
information  has  traditionally  been  available  with  operating  system  documen¬ 
tation  and  its  updates.  It  may  t  hereto,  r  be  found,  unrestricted,  t-i.  college 
and  university  campuses,  in  a:.cociat;on  with  those  computer  system*  arid 
the  various  related  libraries  A  perpetrator  may  often  be  able  to  depend  on 
a  given  installation  to  be  slow  in  upgrading  to  the  new  version.  In  this  case, 
the  subject  documentation  becomes  a  textbook  on  system  penetration. 

®  The  National  Computer  Security  Outer  has  been  successful  in  com¬ 
pleting  an  evaluation  of  the  Honeywell  SCOMI*  system  at  the  Al  level. 
Others  arc  expected  in  the  future  However,  complexities  of  impleiiienlat ion 
and  of  suitable  evaluation  for  such  systems  arc  considerable  These  lead  to 
high  costs  a  >d  substantial  delays  in  an  environment  of  limited  resource.  The 
Center  publishes  an  Evaluated  Product  Inst,  as  a  service  to  the  community, 
where  information  can  be  found  on  each  product  that  has  achieved  evaluated 
status. 


the  risks  that  Arise  f*om  inadequate  training,  human  error,  mis 
diiortiois,  m  h>ss  of  suitable  accountability  and  supervision,  as 
in  the  Oliver  North  case.' 

TIk*  historical  petspedive  on  Inis1  and  the  noiubh*  lack  of 
technology  that  can  identify  insider  lb  rent  have  led  to  wide 
spread,  blind  trust  of  user  populations. h 

There  is  also  a  patient  •  *1 ’  exernpl  ions  io  policy  guidelines 
in  those  areas  that  req  ire  a  surveillance  oriented  technology.'1 
The'  circumstance  may  no  longer  he  necessary.  Ii  is  in  Ibis 
context,  and  in  Hie  backdrop  of  similar  expressions  of  concern 
found  throughout  tin*  Itil'osee  community,1"  that  this  paper  in 
troduces  and  outlines  some  proposed  charact erisl ics  of  insider 
threat  identification  systems.  The  specific  types  of  concerns  ex¬ 
pressed  throughout  the  I nfosec  eommunily  about  managing  l  be 
risks  from  insider  threat  suggest  a  system  that  consists  of  at 
least  these  five  basic  components: 

(1)  v'apturr  of  detailed  system  and  user  monitoring 
data  through  high  performance  surveillance  lech 
nology 

(2)  Kx pert  system  annivsus  of  a  surveillance  knowl¬ 
edge  base  for  suspicions  events,  with  weighted 
scoring 

(J)  Identification  of  perpetrators  by  an  interactive  ex¬ 
pert  system,  using  the  analysis  results  and  the 

7  The  report  In  tin*  T.*\vrr  ('onmiissimi.  acting  muter  prcsidcnti.il  di 
retliou,  presents  evidence  of  directives  made  hv  electronic  mail  on  sensitive 
computer  systems  at  the  National  Security  Council  that  drmonsi rale  a  loss 
of  suitable  arromit. ability  and  a  me  of  government  computers  to  further 
objectives  alleged  to  be  voimai.v  U>  the  sponsor  \>  policies  anil  objectives. 

*  F i v •“  groups  are  known  to  the  author  to  have  published  in  the  area  of 
in.-iiier  threat  id*'nlilicat  i'»*i.  T\v*»  *>f  I  host*,  t  lie  groups  at  SKI  I  nlern.it  itui.it 
and  13|,  ar.d  al  die  N.itioi  ,d  Computer  Security  Outer  j2],  -ire  characterized 
by  tlieir  tit.es  as  irtrusioii  detect  ion.  The  Sytck.  Inc  group  speaks  of 
analyzing  t  iodition.il,  **  x  i  s » :  n  f  t  audit  trails  l«>i  security  violations  Jl;  On 
page  71  of  tills  reference,  i  idei  the  seel  ion  tailed  K.ukgroimd,  il  stales' 

"Monitoring  of  computer  system  eve  t»*r  security  viol.it ions  vmII  always 
be  nc:c>snr  v .  fa-en  :f  we  perfect  tlie  ability  to  design  sec  ure  computer  svs 
terns  whit  li  u-ian  trust,  we  c-.ii  ii ?’-’er  fully  irusi  their  users.  'I’lie  problem  ot 
e Ate I’iug  legituuale  user.-,  v.T.o  vioh.le  system  security  will  rem.im  a  problem 
which  cm  mo^l  effectively  be  addressed  bvsumity  monitoring. 

Till  rently,  system  seeurilv  olliiers  perform  security  monitoring  of 
computer  systems  by  manually  reviewing  the  system  audit  trail  The  only 
automated  r.clp  ;»*«iiiable  to  them  comes  it:  the  hum  of  audit  meehauisnis 
capable  of  producing  i  rpoi  Is  or  dat.”  ha  ,r*s  which  store  audit  !  rail  data.  Con 
secjucnllv,  tliere  is  .»  great  nrtd  for  more  capable*  autoinalte  t<»,>[s  !■»  assist 
in  this  task.  Tit  is  need,  and  the  lack  of  work  being  done  to  develop  such 
tools.  Vi  as  pointed  out  by  M.irv  Sc  haclcr  in  Ins  dosing  icm.irks  to  the  Eighth 
Nai.ioc.il  Computer  Set.  urily  Conference  Although  in  lflfit).  the  .lames  1* 
Anderson  Co.  produced  an  excellent  discussion  ol  this  problem,  not  much 
seems  to  have  been  done  since  then.”  (see  reference  -17;) 

The  fifth  group,  A.  R  (’lytic  Associates,  with  collaborators  at  Clyde 
Digital  Systems,  has  addressed  insider  threat  identification  systems  as  a 
whole.  Most  of  th?  Ciytle  Digital  Systems  work  has  been  done  on  surveillance 
technology  as  a  foundation  for  such  systems.  However,  the  SentryGA TE 
product  now  in  the  field  also  performs  surveillance  data  analysis  using  a 
small  lumber  of  suspicions  event  tests  with  weighted  scoring. 

0  The  author  has  received  reports  of  a  number  of  instances  where  ex¬ 
emptions  to  government  guidelines  for  monitoring  the  activities  on  erilirally 
SC'lsitive  systems  have  been  granted,  in  the  belief  that  no  effective  te<bno|- 
ogy  exists  in  support  of  sue h  guidelines  In  pari ieidai ,  a  classified  dot  iiimuil 
produced  by  the  Defense  Intelligence  Agency,  called  1)1  AM  50  A,  is  known 
to  contain  swh  guidelines. 

10  The  author  refers  here  to  meetings  and  conversations  with  members  of 
the  National  Telecommunications  and  Information  System*  Security  Com 
mitletr,  staff  personnel  at  NSC  and  NS  A,  SAlSb  committee  members.  Na¬ 
tional  Computer  Security  Center  chiefs  and  others  in  the  government  and 
military  intelligence  community.  There  has  hern  a  unanimous  expression  of 
concern  about  insider  threat  on  .automated  information  systems  and  recent 
reports  of  serious  compromise  to  the  national  interest  from  same. 
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mi rvel Haute  data  sri  for  investigation,  evi<U*tu*e 
gathering  and  ease  development 
(1)  l  uo|s  fora  « I « M  ;i  t  l«'c  I  damage  assessment  limn  I  lie 
mi r vei Hmiee  cl.it *■  set 

(.*>)  Support  inp;ilnHl\  for  reonerv,  hased  on  sm  eess 
fid  damage  assessment  and  (lie  suneillnme  data 


2.1.3  System-event  Surveillance 

Svst:-m  oven!  survcilhinicimludes  lilc  I/O  activity 


,rm  -revue,  TIi.-m-  ..mvcillnmclaln  rlu„;u  „',V,-  I  hr  l  .  -J—M:- 
„f  ,|t,  ,v,wn.  I..  .wr.  a '..l  processes  All  I/O  «»> 
s,.rvi.  r  calls  may  ncd  to  be  monitored  and  I  hr  or  resp.,ii.l„.K 
surveillance  r.i|it  urr*l.  depending  on  'hr  rcqmrcuunt,- 

l)v  s.-crhy  polic  y-  Smiir  i ,,-.1  i. 'i...y  cm,, me  total 
system  surveillance  an. I  may  require  that  .lata  l.r  captured  m 
extensive  ilc, ail . 

Il  is  recommended  H.al  llir  system  even:  surveillance  omd 
■  „u-  i,|M.  .  ..II. a  t  , r, dependent  system  nee.., . I, ting  st;, Indies.  Von 
Iriliuti.’iis  In  I  hr  full  syslr...  surveillance  data  set  should  not 
,1,,,,..., I  0,1  an  rxlri.rti.rn  records  handled  ami  managed 


2.  Internal  Surveillance  of  Aul  oiiinla-.l  In  for  mat  "mu  Sys¬ 
tems 

Methods  of  internal  surveillance  in  an  a.iloinai.al  ...  forma 


lion  system  fall  into  tun  categories.  depending  on  objectives.  >>y  thr  operating  system  ami  system-  manag.  nu  l<  ■  ■ 

Tim  first  i,  passive  .lelcctin,,.  u  l„,  I,  naans  that  I  hr  in  depth  Independence  ol  data  source  and  tuyere,  amp,  r  rt  -  *  ■  ' 

analysis  of  Mirvrillanrr  .lata  is  performed  for  thr  tirtrrti.Mi  of  Import..., .  to  assur,-  .lata  integrity.  rvra  t 
insider  tlireiil  fakes  place  ofT  line  or  off  lioiir.  The  seeond  mav  ing  im Wl  b<  jniulra*t< 

he  eliaraeleri/ed  as  pro  aetive  tleiect ion,  wliieh  means  that  (lie 

surveillance  data  are  tested  in  real  time  for  certain  events  that  2.2  Subsequent.  Drteetioa 

the  lot s  lead,  when  necessarv,  to  ;n.  immediate  protective  re  ...  ,  .  v  r  . 

....  .  -  f  .  -  ,  The  anwlvsis  of  full  system  surveillance  data  fot  <«  rtatn 

spouse.  I  he  oh  iccuve  pro  active  (let edioii  is  t«»  recognize  uiio  11  •  *  ,  ,• 

suspend  processes  U.at  mav  cause  srrtot,,.  m, mediate  damage  kinds  of  suspmmas  events  also  rc,pmo  ...rrrlatto,  w.t  •*« 
to  systeu  Thr  objective  of  ,„h,<..p,rat  m  .Irptlt  analysis  spomliug  .lata  from  pnor  prrm.l.  '  ‘ ‘  *  J 

nf  l lie*  surveillance  (iutuls  rUrriivt-  del n  tint)  of  ,  hr-  . .  subtle  analysis  oh, am, d  .«  d-U-1’  nuhraU-s  tin.  t hr  -  ‘  " 

tl, mats  that  arr,  in  u  hroa.lrr  sense,  damaging  to  .hr  sponsor.  "f  computer  crone  an;  pattrn.s  of  ron.lnr,  hut  • **  '• 

period  of  t  unc.  ivtrrtioi,  ,s  greatly  m.prnvr.S  In  .iital)Ms»f  »  • 
torical  use  patlrms.  Passive  detection  is  characterized  by  the 
2.1  Full-system  Survedhurcu  folu-tti,m  „f  substantial  amounts  of  'lata  for  olMtne  or  off-hour 

...  i  .i  ..i.  .  n...  .  .-riMMi  *n  oerforniuicr  its 

For  convenience  in  subsequent  references,  thr  term  full  analysis,  wl.it  it  ,i,hs  no.  o.  .  m. 

system  surveillance  refers  to  the  rapturing  ami  recording  of  intrndrd  function, 
all  surveillance  data  that  appear  to  have  an  important  bear 

ing  oil  the  successful  .let  eel  ion  of  insider  lineal.  Such  full  2.3  Pro-active  Detection 


system  surveillance  falls  mil urally  into  three  independent  fane 
tinnnl  modules,  referred  to  here  as:  1 )  user-inlt  raelion,  2)  batch 
s.rean>,  and  ii)  system  emit  |t>  . 

2.1.1  User-interaction  Surveillance 

User  interaeii.m  surveillance  imist  deal  with  both  local  and 
remote  terminal  users.  These  are  dialup  users,  or  users  across 
ing  the  system  from  another  mute  on  a  net  wink.  I  his  module  is 
responsible  lor  monitoring  the  information  that  moves  between 
the  processor  and  the  terminal,  including  mulisplaycd  informa¬ 
tion  such  as  esc  a  pc  codes  ami  Con  t  rnl  eo.les*  The  security  policy 
at  sottte  installations  requires  the  ability  (•>  play  hack  a  term, 
mil  session  from  the  surveillance  data  exactly  ns  it  originally 
occurred.1 1 


Pro  active  detection  must  consist  of  a  carefully  limited  St  t 
of  tests  in  order  to  avoid  burdening  the  system.  These  tests  are 
formed  against  the  surveillance  data  in  real  time,  that  ,s  as 
the  data  are  being  collected.  The  amount  of  testing  i*  go, del 
I,v  ee.uritv  policy,  the  potential  system  burden,  and  the  neces¬ 
sity  of  preventing  system-damaging  events.  I'pon  detect,,.,,  of  a 

suspicious  event,  an  alarm  is  sent  to  the  system  security  admin¬ 
istrator  and  the  suspi, ie.ue.  task  is  suspended,  landing ;  a  more 
i„  depth  review  of  the  potentially  damaging  activity.  I  he  tasK 
luav  subsequently  be  terminated  or  rc  activated,  depend, ug  on 
the'  decision  of  the  system  security  administrator,  lmr  some 
tests,  additional  computer  analysis  may  be  usef.d  follow,,, g  do 
teoti.m  of  a  suspicious  event.  Such  analysts  could  be  automatic, 
„t  it  could  require  interactive,  investigative  intervention  by  the 
security  administrator 


2.1,2  I3atrh  Stream  Sitrvcillnurv 

Datrh  stream  surveillanrt1  rrmrds  the  foutents  of  batch  and 
command  control  files  and  the  system’s  responses  to  these  files 
This  module  is  responsible  for  monitoring  the  information  that 
moves  between  a  batch  stream  and  the  processor.  The  seen 
rity  policy  at  some  sites  may  require  the  ability  to  play  back  a 
batch  stream  activity  at  a  terminal  as  though  it  had  been  per¬ 
formed  manually,  showing  the  command  input  and  the  system 
responses. 

**  A  number  of  sites,  where  901  vcillancc  technology  is  m**/  integrated  into 
security  policy  and  procedures,  arc  performing  blanket  monitoring.  This  is 
a  fontmuoiij,  mandatory  capture  oi  all  keystrokes  and  system  responses  for 
each  user  Passwords  are  excluded. 


2.3.1  Dealing  With  Trojan  Horses,  Viruses  and  Worms 

Should  security  rc-quire  that  each  program  it,  the  system 
library  include  a  table  that  lists  the  resources  ncetlcl  for  Us 
execution,  then  a  system  events  surveillance  module  could  ileal 
pro  actively  whl.  clandestine  attempts  to  insert  damaging  log,, 
the  system.  Such  a  table  could  be  interrogated  prior  to 


U  |„  0,„  .-..V  of  Jonathan  i  I’ellont.  suspicion  was  tiunlly  raised  throngl, 

,  otarrvaiM.,,  bv  personnel  that  be  seemed  to  be  access,,, R  Uqp ^volumes 
-  data  As  an  aull, orbed  „sc'.  a.ress  controls  oUeret!  no  pro'e, Uw  '■ 
,ons„r,  „o,  would  the  analysis  of  any  gwc,  day’s  a,t,vme3  necess.mty  have 

;„w„  ;  ...nKic,  pattern  for  susp.cio,,.  However,  bad  . . safer  tinea 

,„ter„  been  employed  to  analyze  surveillance  data  usrng  present  an  V  > 
ctivities  rna-cheil  against  a  user  ,m,,d.  tahte.  u  seen  s  hkely  that  such 
nspirioii  wm, hi  have  been  raised  al  greatly  reduced  levels  of  comprom.se 
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execution.  The  resources  subsequently  requested  by  the  pm 
grain  muld  then  be  teste*!  fur  compliance  with  the1  resources 
authorized  in  the  (aide.  When  lack  *»f  compliance  is  detected, 
the  program  could  lie  suspended.  AppmpiinJe  alarms  could  be 
sounded  and  interactive,  invisligat i ve  piocetlures  initiated. 

The  resource  table  could  be  encrypted.  Access  to  the  de 
c r\  plum  key  ouilil  be  iimiW-cl  to  the  svs1<*m  events  snrvediauce 
module.  In  those  cases  where  fully  automatic  code  genera* 
mg  tools  are  used  to  create  system  hhrary  programs,  the  l.ible 
would  he  ei  'list  rue  ted  and  en<Tvpl  ed  b\  computer,  Tin*  progi  a  m 
output  from  such  a  code  generator  could  go  by  trusted  path  di 
rcctlv  to  write  once  media.  I’his  arr  »nge:netit  could  virtually 
preclude  human  interaction  with  code  placed  into  a  certilicd 
standard  master  library.  The  programs  in  the  system  library 
would  be  copied  from  this  independently  set  tired  master  library 
and  then  periodically  bit  checked  against  it  for  correctness. 

2.4  At  to  lull'd,  Ono-oti-ono  Stir  veil  In  net' 

In  addition  to  tlu*  unattended,  pro  active  detection  just 
suggested,  attended,  oiir-oti  om*  surveillance  of  certain  users  by 
the  system  security  administrator  lias  been  found  useful  as  an 
investigative  tool.13  The  technology  referenced  here  has  been 
in  the  field  for  about  eight  years.  It  is  rhurui  teri/ed  by  high 
performance,  in  that  it  does  not  place  a  burden  on  the  processor. 
The  investigator  or  security  administrator  may  interact  directly 
with  the  process  when  necessary. 

2.5  The  System  Rcifitionship  of  Insider  Threat.  Compo¬ 
nents 

The  surveillance  component  of  an  insider  threat  uh-ntilua 
tion  system  is  the  only  one  of  the  live  components  that  requires 
a  close  working  relationship  with  the  operating  system  and  its 
trusted  computing  based'1  l  he  other  four  coinpom  uts  may  run 
on-line  or  olF  line  as  trusted  application  software.15 


13  There  is  a  product  in  the  field  th.it  operates  a l  a  Mihjcit  object, 
primitive  pair  level,  employing  an  S  g.ife  lei hm*|ogv.  A  discussion  of  these 
concepts  is  found  in  ip'Vmut  Ifij.  A  te»  lmic  ,d  overview  of  t  Ins  product,  called 
C’ONTKL,  can  he  obtained  from  Clyde  digital  S> stems.  This  feclmologv  li.is 
been  used  in  concert  with  system  surveillance  let  hnol.igv  in  criminal  inv-es 
tigatious  nu  automat ed  information  systems  It  allows  an  investigator  t>» 
dy luunic.ill v  link  t<>  an  arbitrary  given  terminal  .imi  smveil  all  information 
moving  between  that  ter'.imul  and  the  pion-ssor  The  perpetrator  is  unable 
to  detect  the  preterite  of  tbusmie  on-orie  sinvedl.ince  activity  The  session  is 
recorded  aucl  the  results  can  be  lonip.ired  fur  added  pcrlec  tmn  «»t  evidence 
with  the  raw  surveillance  data  set. 

^  The  operating  system  c»r  the  trusted  computing  base  would  contain  thr 
instructions  .  *r  transfer  of  program  execution,  at  appropiiale  times,  to  the 
survrillam r  modules.  Iu  order  for  these  brant  liiug  instructions  to  be  inserted 
dynamically  into  the  trusted  system  without  interfering  in  any  way  with  its 
operation  and  certification,  the  logic  for  insetting  the  surveillance  modules 
depends  on  a  certain,  precise  knowledge  of  ihe  subject  target  system  The 
target  system  need  not  have  any  panic  ular  .iccominodation  in  anticipation 
of,  or  in  an  attempt  to  support,  the  surveillance  modules  outside  oi  its  nor¬ 
mal,  certified  function.  This  broadly  »  haraeterizes  the  relationship  between 
the  trusted  computing  base  and  the  surveillance  technology  now  in  the  ticld. 

15  The  remaining  four  components  of  .an  insider  threat  ide-itilic  at  ion  sys¬ 
tem,  namely  expert  system  analysis,  interactive  investigation,  damage  as 
sessment  and  recovery  support,  need  not  impa.l  the  certification  of  the  tar 
get  system  under  surveillance  in  any  way.  They  may  be  executed  as  trusted 
application  software  in  an  oil  hour  mode'  In  some  cases  it  may  be  appro 
pciate  to  place  these  components  on  a  system  dedicated  to  insidei  threat 
identification  in  support  ot  a  number  of  target  systems  under  siirveiliancc- 


2.0  Surveillance  Issues  for  Optimizing  Detection 

In  order  to  optimize-  the  ability  to  detect  suspicious  events 
through  analy  sis  of  tin*  surveillance  tbit  a  set ,  it  is  r.-'Mid  ial  I  lint 
polit  y  dictate  mandatory  sm  vetllam  t  10  To  achieve  m.i mint  oi  \ 
surveillance,  the  technology  must  be  Uitnpc-t  resist  nut .  must  md 
burden  the  processor  anti  must  be  a  cost  rlfeetivr  adjunct  to  a 
certified  trusted  computing  base.  I  Ins  is  necessary  in  order  to 
enforce  such  a  policy  and  In  make  it  viable. 

Recent  experience  with  a  criminal  penetration  of  a  secure 
system  has  emphasized  Ihe  need  for  correct  operation  of  the 
surveillance  component ,  even  when  the  access  controls  of  the 
trusted  computing  base  are  penetrated  and  its  alarms  and  an 
diting  turned  off.17  This  level  of  tamper  resistance  is  lust  as 
sured  when  there  arc  no  operating  system  service.-'  that  make 
reference  to,  identify,  or  grant  access  to  the  surveillance  com 
ponent.  This  is  a  ilegrte  of  concealment  Such  concealment, 
or  ‘Mata  hiding, *’,ri  lias  proven  itself  in  the  held  by  delb  ering 

1,1  1>im  tvtior-.ary  surveillance  may  bt-  used  to  gather  evidence  upon  «‘5 
tablished  suspicion.  However,  permitting  discretion  reclines  the  t„ni|irr 
resistance  of  t  he  surveillaiu  «*  fumtinn  by  graining  dis«  ret  inn.try  access  at 
some  level  of  aiilhori.  at  ion  fot  enabling  and  thus  for  disabling  surveillance 
In  addition,  the  chain  of  evidence  to  the  initial  c niupnuuise  will  almost  al 
wavs  be  lost;  the  per  pet  r.ilor  may  escape  notice  and  the-  innocent  mav  conic 
under  suspicion  Incomplete  surveillance  data  limits  the  ability  ol  expert 
system  analysis  for  suspicions  events  In  most  cases,  traditional  audit  tech¬ 
nology  is  regarded  .is  too  limited  in  del  ad  and  too  burdensome  to  the  target 
system  to  be  used  in  a  manner  siiHieient  t"  the  demands  ol  optimum  ex¬ 
pert  system  analysis.  In  some  cases,  suspicion  can  only  be  established  at  a 
prompt  level  for  certain  dangerously  privileged  programs. 

in  «ui  investigation  by  ihe  I'M  on  a  ssstein  foi  which  the  author  had 
responsibility,  an  intruder  was  observed  to  penelr.V.r  the  access  controls  of  a 
secure  operating  system.  The  intrusion  was  first  noted  hv  a  svstem  security 
administrator  when  scanning  the  job  ououe  during  the  course  ol  a  normal 
procedure.  A  suspicious  activitv  was  noted  and  the  security  ollieer  executed 
one  on-one  surveillance  against  the  remote  termiii.il  under  suspicion  The 
system  had  a  monitoring  policy  v. hiili  was  being  enforce!  by  mandatory, 
blanket  surveillance.  This  survc.li.inc  e  also  teiorded  tin-  activities  of  the 
security  olliter  in  observing  the  perpetrator  directly  The  perpetrator  was 
observed  to  penetrate  all  levels  of  system  privilege  and  then  to  disable  the 
alarms  and  auditing  of  the  trusted  comput ing  base  Certain  features  of  the 
penetration  pointed  clearly  to  insider  knowledge  «.|  the  system  and.  t  lieiefore, 
a  knowledge  of  the  existence  of  the  surveillance  function,  hi  over  2f>  hours 
of  recorded  activity  on  the  svstcin,  the  perpetrator  committed  t  rimin.il  nc  ts, 
but  did  not  disable  t  lie  surveillance  fuiu  t  ion.  A  c omplf lc  c  ham  of  evideiu  e  to 
tin*  initial  rompioimse  was  located  and  extracted  from  the  raw  surveillance 
data  set. 

18  (.  t  page  It),  station  -l.  I  3.14  of  the  Criteria  \  1 1  »*u  t  lie  subject  of  t  lass 
Al  operation. .1  assurance,  ihe  M.itional  ('omputei  Security  (’eider  stales 
“The  T(  II  shall  inc  or porat r  sip.n > I n  ant  use  of  layering  abst  ract  nu.  and  data 
hiding  ...”  In  the  same  context  u  states  “The  TCB  shall  niamtaie  pro 
cess  isolation  through,  the  provision  ol  distiml  address  spaces  under  its  con 
trol  ...”  It  also  states:  ‘‘The  TCB  shall  maintain  a  domain  for  its  own  ex 
edition  that  piotccts  it  from  external  intei  ference  or  tampering  ...”  These 
concepts  should  also  be  applied  independently  to  the  design  and  nnplcinen 
intion  of  surveillance  modules,  'lhc  user  interaction  stirveillaint  technology 
now  in  the  field  utilizes  each  of  tamper  resisting  mechanisms  in  its  relation 
ship  to  the  TO).  Therefore,  should  a  penetration  of  the  TCB  occur,  an 
independent  layer  of  logir  maintaining  pnu css  isolation  with  control  over  :ls 
own  distinct  address  space  can  retain  bs  integrity  ami  moniuu  the  penelra 
tioti  Footnote  17  describes  such  an  instance  In  addition,  :t  is  proposed 
that  the  branching  locations  dynamic  ally  inserted  into  the  TCB  for  transfer 
of  process  execution  to  the  surveillance  modules  be  restricted  information 
This  adds  an  additional  increment  of  tamper -resistance.  It  should  be  noted 
here  that  the  alteration  of  a  given  branching  location  in  the  TCB  by  a 
perpetrator  will  not  likely  disable  certain  advanced  surveillance  technology 
currently  in  the  field.  Because  of  the  independence  of  the  surveillance  mod 
ules  and  their  capacity  for  dynamic  insertion,  restricting  tin-  information  on 
the  brandling  locations  does  not  impact  the  public -knowledge  practices  of 
key  operating  system  vendors  feu  source  code  on  Cl  and  C2  rated  systems. 
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nuimliitnry,  iimt  intcrarticin  joirwilhiiut*  that  ciiiuinl  hr  intrr 
ruptrtl  hy  any  p.irtuulur  piivilrgnl  um*  «»f  I  hr  trusted  nnnpiil 
ing  I).!*'!1  or  oprrnlmg  sysloni.1  1  I  In*  siirvrilhuicr  «lat a  srt  tan 
alwt  hr  made  imu*r  tamper  rrsislunt  lh:<*ngh  tin*  mm-  t»f  c*xiM i nj* 
write  once*  media,  sueli  as  optical  storage,  and  llnough  satiable* 
riUTvptiou. 

2.7  Surveillance  Field  Experience 

Field  experience  with  existing  User  iuleraclinn  surveillance 
treliiiediigv  lias  also  lieen  particularly  rummaging  for  its  high 
perfuriHiiiice.  Whrn  hl,mkrl  monitoring  (the  ouitiiimnis  cap 
tine  of  all  keystrokes  amt  system  responses  at  tin1  terminal  fur 
each  user,  excluding  passwords)  of  all  users  is  applied,  which 
is  the  inode*  required  by  security  policy  at  a  number  of  sites, 
the  user  interaction  surveillance  technology  does  not  reveal  it 
self  to  the  user  community  as  an  observable  burden  on  the 
system.  Measurements  to  date  of  processor  time  requited  for 
the  execution  of  this  surveillance  function  consistently*  lie  In* 
low  3%.?"  This  i  vperience,  together  with  recent  development 
work  in  the  system  event  area,  indicates  an  expectation  of  high 
performance  for  total  system  surveillance,  which  would  include 
all  three  classes  of  surveillance  and  the  capturing  of  data  at  a 
detailed  level  for  all  users. 

2.8  Cost  Eftecf.ivoiicss 

Cost  elTect! veuess  in  surveillance  technology  is  essential 
to  the  viability  of  a  mandatory,  full  system  surveillance  pol 
icy  The  cost  components  involved  in  making  effective  use  of 
surveillance  technology  on  existing  systems  have  been  relatively 
modest.  These  components,  from  experience  in  the  field  with 
user-interaction  surveillance,  are  limited  to  acquisition,  integra¬ 
tion  and  training.  The  acquisition  costs  have  been  particularly 
modest.  Integration  invokes  only  updates  and  extensions  to  se 
curity  procedure*.  There  are  no  changes  to  the  certified  trusted 
computing  base.  The  user  interaction  surveillance  technology 
can  In*  dynamically  inserted  into  a  system  in  normal  operation 
without  interfering  with  its  current  processing  in  any  way.  It  is 
this  technique,  together  with  concealment,21  that  precludes  the 

Tin*  surveillance  lechtmlngy  now  ill  tlu  tirld  in  not  nicrssihle  by  services 
provided  by  the  ’printing  system  >»r  Trusted  ('uuipinttig  Host*  with  wliii  h  it 
is  installed. 

2"  The  measurement  cl.it .t  dm  user  iuirr.n  l ion  snrveilluu*  <•  is  limited. 
Howrcer,  t he  tests  run  with  instrumental  jon  in  the  code  for  processor  use 
measurements  consistently  indicate  a  utilization  of  less  than  \S%  for  the 
surveillance  system  in  relationship  to  all  oilier  activities  over  vaimus  sample 
increments  ol  tune.  The  tests  were  m.ide  for  the  blanket  monitoring  mode, 
which  is  tin*  maximum  system  loading  condition.  The  job  mix  was  typical 
of  a  highly  interactive  environment. 

21  The  requirement  of  a  correct,  continued  execution  of  the  operating  sys 
tern  and  the  trusted  computing  li.ise,  together  with  the  tasks  in  execution, 
under  dynamic  insertion  of  surveillance  let  h  nolog  v  is  a  valuable  form  of  mea 
su  rattle  ass  ill  ai  ire  of  correct  operation,  liiiutiotial  independence  ami  doiinnn 
isolation  of  each  On  this  subject,  and  relative  t.i  the  operational  assurance 
of  a  trusted  computing  base  for  class  Al.  the  National  Computer  Security 
('enter  state*  the  following  on  page  4U,  set  tioa  4.1  3  1.1  of  the  (Yitrria  |lj: 

"The  T('l»  shall  maintain  a  domain  for  iis  own  execution  that  pro 
tec  Is  it  from  external  interference  or  loiiiprimg.  .  .  .  The  TCP  shall  main 
tain  process  isolation  through  the  provisiun  ol  distinct  address  spaces  under 
its  control.  The  TCU  shall  be  internally  sttuctured  into  well  defined  largely 
independent  modules.” 

In  addition,  by  precluding  access  to  the  surveillance  tec  hno'ogy  through 
the  services  of  the  trusted  computing  base  and  through  the  operating  sys 
tem.  tin  certification  uf  these  components  is  not  effected  hv  the  presence  of 
the  complementary  surveillance  functions  as  it  supports  the  identification  of 
insider  threat.  This  form  of  concealment  therefore  has  an  important  benuug 
on  the  question  of  re-certification,  and  its  costs,  whfr-*  access  controls  and 
surveillance  are  both  required  by  policy 


ihciI  fur  ro  iortifir;i(i<iii  of  tin-  truslrd  computing  liasr  :<ml  llic 
higli  n.hts  for  SiiiiH* . 

II.  is  is  the-  primary  nmf  t  i  lm  It  m*  t  <  •  tlu*  rxiciirnt  cusl  of 
fc*i  I  i vciu'ss  uf  nsrr  inte  raction  surve  illance  in  l|u*  field  Imlav. 
(t  is  copied  on  and  executed.  It  tuns  unat  t  ended  and  mi 
interrupt  inlr.  Ibis  favorable*  experience  suggests  the  itnpor 
tame*  ul  ret  aim  m;  1  be*  capability  uf  dynamic  nise  i  lion  and 
concealment  in  the  implement, it  mu  of  tlu*  system  event  and 
batch  stream  modules,  which,  together  with  the*  existing  user 
inU-ructum  module  s,  would  make*  up  full  system  surveillance. 

3,  Suspicious  Event  Analysis 

1  be  analysis  of  data  gat  hcred  t  li  rough  tin*  i  tit  ei  uni  stir  veil 
lance  of  automated  information  systems  appears  to  have  only 
recently  been  addressed  hv  leehnical  piofosionals  in  the  Infosee 
community.  'I'here  appear  to  be  just  five  groups  that  have  pul) 
lished  papers  in  I  he  field.  In  addition,  ope  of  tin*  intelligence 
agencies  is  known  to  have  implemented  suspicious  events  tests 
for  the  UNIX  environment  and  has  had  such  tests  in  operation 
fora  few  years.  Others  may  be  practicing  some  audit  trail  anal 
ysis.  22  1  he  UNIX  operating  system  piovides  number  of  user* 
•Hid  system  activity  audit  t  rails  of  limited  detail  I  \>  that  may, 
never*,  heless,  be  used  to  detect  i  nap  pi  op  rial  e  conduct  wit  h  some 
degree  of  suc  cess.  However,  such  dat  a  lac  ks  the*  detail  necessary 
to  invest  igate  t  he  subtleties  of  many  forms  of  damaging  con  dm  I 
by  authorized  users.2'* 

3.1  The  Intrusion-detection  Expert  System 

A  papei  by  Dorot  hy  K.  Denning  of  SR  I  I ntermit  unud,  one  of 
the  five  groups,  appeared  in  early  I  based  on  work  reported 
internally  in  l!IS.»  ll.ij.  I  his  paper  propost*s  a  niocU'l  for  a  real 
time  intrusion  detection  expert  system  (IDKS).  "Tin*  model  is 
based  on  the  hypothesis  that  exploit  at  ion  .  .  .  [will  involve 

an  abnormal  use  of  the  system  ’  plj.  Penning  points  out  four 
factors  that  motivate*  the  development  of  such  a  system: 

(1)  Most  existing  systems  have  security  flaws  that  rrn 
dcr  them  susevpt ihlc  to  intrusions,  penetrations,  and 
other  forms  of  abuse;  finding  and  fixing  all  these  de 
liciencies  is  not  feasible  for  technical  and  economic 
reasons;  (2)  Kxisting  systems  with  known  flaws  are 
not  easily  replaced  hy  systems  ihat  are  more  secure 
mainly  because  the*  systems  have  attractive*  feature's 
that  are  missing  in  the  more-secure  systems,  or  else 
they  cannot  be  replaced  for  economic  reasons;  (3) 
Developing  systems  that  are  absolutely  secure  is  ex 
tremely  diflieult,  if  not  generally  impossible;  (  I)  Even 
the  most  secure  systems  are  vulnerable  to  abuses  by 
insiders  who  imsuse  their  privileges.  |3| 

22  It  is  likely  tli.it  sonic  manual,  unci  it*  some  degree  automated,  analysis 
of  certain  inulitii.nal  audit  trail  data  lias  been  practiced  in  remit  year*  by 
various  government,  military,  contrac  tor  and  private  sector  groups.  However, 
no  formalization  of  an  insider  threat  identification  system  discipline  appears 
to  have  developed. 

I* or  example,  t lit  operational  support  ■>!  an  a'llnimiul  uilorin.il  ion  sys 
k in  by  security  administrative  and  system  management  personnel  requires 
the  use  of  dangerously  privileged  programs.  Such  programs  include  those 
that  are  able  to  alter  passwords,  set  up  accounts,  change  levels  of  access, 
install  privileged  programs,  disable  alarms,  alter  traditional  audit  media- 
nisms.  and  alter  the  operating  system  or  trusted  computing  base  In  the 
case  oi  what  appears  to  be  an  authorized  use  of  sin  h  program*.,  suspicious 
activity  can  best  be  assessed  at  the  prompt  level  An  rllective  investigation 
that  confirms  suspicion  or  establishes  innocence  also  depends  critically  on 
evident  e  gathered  at  tie  keystroke  and  system  response  level. 
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These  saute  factors  represent  eoneerns  throughout  the  coin 
inunity  relative  to  insiders  engaged  in  conduct  i li.it  violates  se 
entity  polity.  Such  persons  may  <i!s«»  mp-jigr  in  inliusivi-  heli.iv 
inr  l  h rough  igin iranee,  el  t  or  or  in.il leasa nee. 

In  the  1 1 ) l\S  approach  jT,  a  Mjl»;n  t  or  gionp  of  is 

elia r«ieteri/ed  1>Y  an  activity  prolilc  with  resju-ct  to  l  1m*  ob/rc  fs 
HortHidl)  acii'ssed A  1  I  lie  .nidit  record  data  ol  the  sxsletn  ate 
tested  to  detect  abnormal  usage  by  mulching  them  statistically 
against  t|u-  activity  pmliles.  The  ability  to  update  the  activity 
prolib  s  am |  to  change  t  lie  pattern  mat  clung  i  ides  implies  an  ex 
pert  system  where  a  portion  of  the  surveillance  knowledge  base 
nia v,  in  a  statistical  sense,  learn  from  individual  use  patterns 
over  a  period  of  time. 

\  he  value  of  these  technique*  can  he  extended  to  oil  line 
or  oil  hour  analysis,  including  cross  correlations  of  use  pat 
terns  and  their  corresponding  activity  profile's  with  prior  period 
data-  This  and  other  suspicious  event  tests,  which  are  amenable 
to  subseepnut  m  depth  analysis,  are  further  enhanced  hv  I  In* 
greater  detail  of  surveillance  dal  a.  Kir  example,  it  is  possible  to 
support,  at  a  keystroke  level,  activity  profiles  for  certain  users 
who  execute  dangerously  privileged  programs.  Such  detailed 
data  will  permit  the  detection  of  an  anomalous  or  peculiar  use 
of  selected  interactive  programs.  This  is  also  the  case  for  critical 
System  services  and  hatch  command  sequences. 

3.2  Detection  By  Pie-nsses.sed  Intrusion  Patterns 

Other  work  on  intrusion detection,  related  somewhat  to 
the  SRI  International  activity  [;j  ami  13],  wa*.  reported  at  the 
tftli  Annual  National  Computer  Security  Conference  in  Septem¬ 
ber  by  Lawrence  U-  llalmc  ami  John  Van  Horne  of  Sytek, 
Inc.  (1,  ll)  ami  lfij.  This  work  was  based  on  a  fixed  set  of  pre 
assessed  intrusion  patterns.  Functions  of  certain  fields  found 
in  trade  onal  audil  records  form  what  they  have  called  fra 
hires.  1  ammeters  in  these  features  are  set  to  values  found  to 
characterize  normal  user  patterns  bin vd  over  some  number 
of  sessions  of  a  given  kind.  These  features  are  then  used  to 
discriminate  between  normal  and  intrusive  behavior.  Success 
fill  features  are  combined  to  create  an  activity  profile  for  each 
user.  It  seenis  intuitive  t fiat  higher  resolution  in  the  data  tested, 
that  is,  greater  session  detail,  would  improve  the  discrimination 
possible  by  this  technique.  In  particular,  certain  tested  features 
Were  reported  to  have  tailed  for  lack  of  data  of  sufficient  quality. 
In  conclusion,  the  paper  slates  in  part:  “It  is  also  important  to 
determine  what  other  monitoring  data,  not  normally  contained 
in  audit  trails,  would  In*  useful”  j-lj.  More  work  on  generic  fea¬ 
ture  development,  bused  on  Detailed  system  surveillance  data, 
is  indicated  by  the  successlul  features  reported. 

A  subject  may  b.  characterized  a-s  a  person  or  a  pmgiatn  winch  acts 
upon  an  objerf  within  the  Automated  informal  ion  system.  An  object  may 
be  characterized  as  an  Vein  of  information,  sm  h  as  a  rei  orti,  a  tile,  u  system 
table  or  a  memory  structure  It  may  also  be  a  program  The  access  of  a 
given  object  by  a  given  subject  is  mediatrd  by  a  security  kerne/  which  im 
ploruents  a  reference  monitor  to  validate  each  act  ess  The  reference  monitor 
"Ms  introduced  in  a  report  by  James  P.  Anderson  (.'«•  in  1072  |12J.  This 
report  describes  the  concept  of  “a  retVieinc  monitor  which  culottes  the  .nr 
tli«ti.:ed  ac«ess  iidatiimslnps  bel  .Veen  snbji-i I:,  and  ultjcds  «d  a  system. "  A 
lefcrencr  I'aJidat /oil  i.’iec/iaiijsin  was  further  deb  ai  d  as,  4'an  implementation 

of  the  reference  monitor  concept.  ..  .  that  v .did.it es  each  reference  to  il.ua 
1  r  programs  by  any  user  (program'}  against  a  list  of  authorized  types  of 
reference  for  that  user”  The  Criteria  of  that  National  Computer  Security 
Center  defines-  a  security  kernel  as;  “The  hardware,  firmware,  and  software 
elements  «>f  a  trusted  computing  base  that  implement  the  referem**  monitor 
(t>ncept-  I[  must  mediate  all  accesses,  be  protected  trom  modilu.dion,  and 
be  verifiable  as  correct.” 


3.3  Intrusion  Detection  by  Aimlysis  of  System  Service 
Culls 

II..-  Wot  k  by  Jrfluy  0.  Kuhn  «d  the  Nntiiui.il  <  ‘Miipulci 
Si-cunt  v  ('cut  ci  was  .i|s«»  i  cjioi  i  cti  in  tiu*  IH  h  V  :i  n  ii.d  National 
(. ’lunpiitcr  Security  (  \  mi  hi  em  i*  .2  .  Ibis  'vurk  is  li.isctj  mi  n  it 
anal  vmn  «d  t  hose  system  M-rvio’  tails  ibal  an*  iim-IuI  in  di-tect 
i  ng  i  n  I  ru  sit  in  t  as  l  ei  t  >n  led  b  \  t  i.iflili'Mi.i]  audit  Mail  1  cch  ii  i  <|  urs 
In  the  colic!  u  mi  >i  i  of  tin-  ji.ipci  .  Kuhn  rcpiU  Is  I  hat  “an  cx.iuii 
nation  of  updating  system  pom  lialhni  loibnnpio  ami  cuiivnt 
auditing  methods  indicates  th.il  ni‘»sl  sophist  uiiici!  \  iol.il  urns 
of  svstcni  see  hi  it  y  will  be  con  i plot  el y  u  inlet  <‘*'f  cd ,  lea  \  i  ng  pot  on 
tlally  no  t race  in  f  In  audit  logs  at  all  J'J1.  1  his  is  disappoint  mg, 
but  not  uuexpci  tcd.^'’  ll  is  in  tMiimeinicd  that  system  c\eul 
Mir  veil  la  nee  data  be  correlated  with  User  ml  d  act  mil  and  batch 
stream  surveillance  data.  As  Kiibtt  points  mu  |2  .  t  iiese  data 
should  he  gathered  at  the  lowest  possible  levels. 

If  the  data  are  iu»|  gathered  by  a  mandatory  mcchanisii. 
that  is  secure  fiom  Inntptiing  even  when  i  he  tm  ted  eoiuput 
ing  base  is  pen  el  rated  and  all  pi  i  vi  leges  coin  pi  •  »mi>en,  then  nm 
analysis  of  those  data  is  based  on  potentially  hunted  or  lo.-t 
informal  mu  and  on  possible-  bisiiili,i'innlioiiT‘  Nevertheless,  a 
variety  of  suspicious  event  lests,  together  with  techniques  for 
evaluating  use  putt  crus,  have  had  some  sue  i  ess  m  d»'t  eel  mg  cun 
duel  that  violates  security  policy,  f  orrelali'd  data  on  system 
service  calls  can  oiilv  enhance  tli.il  success  by  extending,  tin* 
tests  that  can  be  performed  and  by  ratifying  the  cxpec.ed  rcla 
tionslup  lietween  system  service  activities  and  user  interact  mu 
or  hatdi  stream  activities.  Alternatively,  such  data  could  hr 
used  to  disclose  an  unexpected  relationship,  indicating  a  par 
ticiilailv  subtle  ami  sophisticated  abuse  ol  the  system  and  its 
trusted  computing  base. 

Tiu*  author  has  proposed  the  collection  of  full  system  Mir 
vrilhmce  data  by  an  N  g.r/e  technology.  This  technology  modi 
ati*s  and  surveils  a  common  data  path  between  subject  <»h/tvf 
pniiiit  i  ce  pairs  (b  .  I  Ins  is  flu*  technology  that  was  used  to  im 
piemen!  tiir  existing  u>er  interaction  surveillance  system  now 
in  the  lieM.2' 

?'S  I’,.,  >|  ni -It*  If  dfvrihrs  .ill  iuVrst  i;;,ilioii  lut.  •  -»ti  :tifUan««-  iriiiun.il 
cnmlm  t  « > n  .i  sn  nit-  :.y:U«*iti  wli  -re  I  lie  pel  pel  i.iloi  left  n«*  cvidri.ee  id  t  hr 
foi  ni  o|  ail. Ill  luj's  .M  al.  Hills  These  no  hamsiii*  were  tinned  * -ti  bv  tin* 
per i>i-i  i al.»i  In-tore  pfoi-rrding  with  llu-iiime 

Ut-I.U  im-  1 1*  l  hot*  «  oui  ci  ns,  !..w\o-ii*e  U  Halioe  .Mill  .I’ll”  ^  *• Tl 

si.»u*  »! 

‘‘An  .ml <Mii.il u  I »h*1  [•>  assist  m  tin1  task  i*l  senility  moml  omig  vm*iiM 
recpnri*  dal.i  about  user  ai  I  iviiy  on  1  In  sv*>tciu  Audit  l  mils  alic.idy  provided 
bv  tin-  system  air  one  m  ui't*  »  I  mk’Ii  il.i'a  l  liey  lia**-  tin  advantage  *hat 
they  an*  ,ia  ruuuiuni.il  amt  pr.ulical  soiine.  siiuc  >lu-ir  use  w.-uld  lepuire 
the  , uitoiu.it ii  mioiiiIoi ir.j*  l.ml  oidv  t«*  inlctpiei  tin*  ilata  anil  not  o’llcit 
it  On  the  oilier  hand,  the  disadvantage  •’!  the  use  ■>!  .auhl  trails  should 
he  re< tigm.'i’d  They  may  n**t  h.-vr  been  t»iie,in.dh  intended  t“r  seiUr-fy 
pul  poses  .nut  n«’t  tolil.iiii  enough  se.  a  riiy  i  elc'-i  ut  m.tU-o.il  I  lu*  amin 

inei'lianisiii  may  iit*t  f  >«'  set  nr  e  it  sell,  so  that  'lie  ambl  il.Oa  it  t,r‘*iliurs  may 
be  of  ipir.sl  mii.ililt'  iniegnty  ' 

]n  reference  ■(*!  **"  p,.j*es  1  ami  1  tin-  rraih-r  Will  had  a  <tis;  ussion  ot 
.S’  gates,  -mil  .ig.nn  on  pages  11  .aid  U  1  or  simplicity  lieu*,  t  he  author  has 
icunliined  the  iot  a)  user  niter. it  t i.'ii  S  gate  -mil  the  rem,.|,*  t-.-miui.il  S  gate 
into  the  siugu-  surveillance  model.  < idled  herein  the  user  imera.  i i.m  simtil 
lame  ntoduh-  In  it  .dily.  Mils  eapabditv  is  repiesi  tiled  l*y  in-  re  thi-i  >*im- 
soft  waif*  module  with  independent  domains  in  the  existing  nnph  niciH.d  umi. 
Similarly,  the  system  tall  S  gate  ami  1/0  call  S  gate  are  loinbinrd  m  wl»  .t 
has  Iipp  i  termed  the  system  event  Mirveillarue  module  f.*i  simplicity  in  d.s 
ctissimi.  The  history  of  S  gate  .‘•vclopnirnl  is  presented  on  page  3  H  *hiit 
X  (*lydr  is  recognized  tor  the  design  and  implement. it it*n  <*t  the  fust,  and 
six TCbsful,  S-gate,  with  the  origin,  u  concepts  gning  back  to  I  Dm.  1  bis  work 
was  done  at  Clyde  Pigital  Systeu  s,  under  the  direi  tioe,  u,  the  author  and 
with  private  funds  Also,  a  discussion  of  sidy.-,  t  t»hject  /irijmfiw*  pair>  *nay 
be  found  on  pages  11  and  12. 
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3.4  Computer  Security  Throt  Monitorinj;  and  Surveil- 
lance 

A  iv[n»rl  i  Hllllcd  “(  A ii ii |i u  1  c'f  Si  cnril  v  IIim  .iI  \b uni i  t\ ng 
;nid  hiirvi-ilbipi  r  was  wiillcii  und'.u  cniitr.icl  iSl'iiMilUU  by 
j  ;,:„cs  I’.  A  mlii  son  I’i..  in  early  1‘IHi)  17  .  I  lie  slmly  was  |u» 
f,  »rmed  fur  "I  lie  purpose  nf  mipioving  ...  I  In*  I'ninpuU-r  see  m  il  y 
auditing  and  ,.ur\ eillance  capability  « »f  the  customer  s  :.\  sii'HM 
(Seclimi  I .  I  .  I  ul  mduiTnm  !  7  ).  F«»r  hmkgroHurl  (Scctw.n  12). 

I  lie  u  j>‘»i  l  >t  alt  s  in  pad : 

Audit  traiU  are  taken  In  t  lie  nistoruer  mi  a  relatively 
long  term  (weekly  t»r  monthly)  basis.  I  Ins  data  is 
accumulated  in  conjunction  with  uurmal  systems  ac 
counting  programs  I  he  amhl  ilata  is  derived  from 
SMI  record*  collected  daily  frum  all  machines  in  the 
main  anti  Special  ('enter.  I  he  data  is  temporarily  com- 
sidid.Ued  ;ntu  a  single  lilt*.. .from  which  the  various 
siiiiiiuarv  accounting  and  audit  trail  reports  are  pro 
ducetl  After  the  various  leporls  aie  generated,  the 
entire  daily  collection  of  data  is  transierred  to  tape. 
Several  years  of  raw  accounting  data  from  aU  systems 
art*  kept  in  this  medium. 

Audit  trail  data  is  (list  rihuted  lo  a  variety  of  individu 
als  for  review....  I  his  includes,  activity  security  ojh 
errs  ft .r  some  application*  located  under  their  purview, 
lint  the  majority  ;g«»es  to  the  customer’s  data  pro¬ 
cessing  personnel.  I* or  the  most  part  the  users  and 
sponsors  of  a  (bit a  base  of  an  application  are  nut  the 
recipients  of  security  audit  trail  data.  ,17j 
The  term  SMF  means  system  management  facilities  and 
refers  to  tradition;;!  audit  trail  information  collected  on  IBM 
mainframes,  such  as  session,  lime,  resource  use,  user  identifi¬ 
cation,  programs  run,  files  opened,  reads,  writes  and  related 
statistics.  This  section  <»f  the  report  goes  on  to  characterize  the 
value  and  the  limitations  of  this  class  of  raw  surveillance  data: 

Security  audit  trails  can  play  ;m  important  role  in  the 
security  program  for  a  computer  system.  As  they  are 
presently  structured,  [these  datai  are  useful  primar¬ 
ily  in  detecting  unauthorized  access  to  jibs.  1  he  cur 
rently  collected  customer  audit  trails  are  designed  to 
detect  unauthorized  access  to  a  dataset  by  user  iden 
tifieis.  However,  it  is  evident  that  such  audit  trails 
are  not  complete.  I  sers  . . .  wit  h  direct  programming 
access  to  datasets ...  may  operate  at  a  level  of  con 
trol  that  bypasses  the  application  level  auditing  and 
access  controls.  In  other  systems,  particularly  (lata 
management  systems,  the  normal  mode  of  access  is  ex¬ 
pected  to  lie  interactive.  Programmers  with  the  ability 
to  use  access  method  primitives  can  frequently  access 
databa:  e  files  directly  without  leaving  any  trace  in  the 
application  access  control  and  audit  logs.  Ruder  the 
circumstances,  such  audii  trail  concepts  can  do  little 
mop*  than  attempt  to  detect  frontal  attacks  on  some 
system  resource 

Security  audit  trails  can  play  an  important  role  in  a  se 
curily  program  for  a  comp-  ter  system.  As  audit  trails 
are  presently  structured  on  most  machines,  they  arc 
only  useful  primarily  in  detecting  unauthorized  access 
to  files.  For  those  computers  which  have  no  access 
control  mechanisms  budt  into  the  primary  operating 
systems,  the  audit  trail  hears  the  burden  of  detecting 
unauthorized  access  to  system  resources.  As  access 


control  mechanisms  are  installed  in  (Ik-  operating  sys¬ 
tems,  the  need  for  security  audit  frail  data  will  be 
even  greater:  ii  will  nut  only  be  able  to  record  at 
lempted  unauthorized  access.  Ini!  will  be  virtually  the 
only  method  by  which  user  actions  which  are  autho¬ 
rized  but  excessive  can  he  detected. 

I  Ins  work  oilers  much  valuable  direction  m  the  cm.ipila 
lion  and  organization  <*f  the  traditional,  or  audit  trail,  class 
of  system  surveillance  data  I  lie  report  introduces  a  Mirvei; 
/•*in i  (  M's'foii  structure.  This  nomenclature  describes  ;  system 
for  the  analysis  of  i  aw  audit  trail  data.-'''  System  elements  are 
described  ‘Tor  tin*  automated  generation  «*f  ‘-cciirilv  exception 
reports’*  (Section  I,  Structure  of  a  Surveillanie  System  [17). 
1  he  structure  includes  a  selection  program  that  operates  on 
the  raw  audit  trail  data  and  certain  selection  parameters,  plus 
a  surveillance  program  that  operates  «»n  certain  resulting  scs- 
sioii/job  records.  'This  is  used  together  with  the  audit  history 
data  to  produce  security  exception  reports. 

3.5  Suspicious  Event.  Testing  and  Weighted  Scoring 

The  fifth  group  publishing  in  this  now  field  consists  of  the 
author  and  his  associates  Robert  A.  Clyde  and  James  1).  Gates 
at  Clyde  Digital  Systems.  These  papers  are  found  in  the  pro¬ 
ceedings  of  meetings  of  the  Insider  Threat  Identification  Sys 
terns  Working  Group  ,b,  7,  8  and  T .  'I  hc*  paper  by  Robert  A. 
Clyde  '8;  discusses  the  su.  .icious  oven*  testing  arid  weighted 
scoring  used  by  the  Sentry  GATE  product  line.29  This  work  has 
been  based  on  the  analysis  of  system-event  and  user-interaction 
surveillance  data.  High  scoring  users  are  presented  as  an  or¬ 
dered  list  on  a  report  provided  to  the  security  administrator. 
Though  limited  in  scope,  numerous  acts  of  misconduct,  includ¬ 
ing  criminal  conduct,  have  been  detected  on  sensitive  computer 
systems  with  this  capability. ,u  Tests  for  misconduct  in  the  use 
of  dangerously  privileged  system  programs  depend  critically  on 
detailed  tu>t*r- interact  ion  surveillance. 

For  example,  consider  a  program  used  to  install  privileged 
programs,  or  the  one  used  to  maintain  access  authorization  ta 
hies  ami  system  passwords.  With  traditional  system  audit  or 
accounting  h  gs,  the  perpetrator  need  only  re-name  the  dan¬ 
gerously  privileged  program  in  order  to  execute  it  undetected. 
Should  the  execution  of  such  a  program  be  detected,  the  tradi 
t it »ii ill  audit  records  will  not  offer  any  information  about  what 
the  user  did.31  For  the  protection  of  authorized  users  acting  in 
good  faith  and  within  the  security  policy  guidelines,  a  record 

I  lie  author  has  us**d  the  word  .snM*ri//a/Ke  to  describe  an  ongoing  mon¬ 
itoring  activity  of  the  target  system.  This  usage  is  consistent  with  product 
literature  that  has  been  in  the  field  for  several  years.  Anderson’s  use  de¬ 
scribes  a  system  th.it  analyzes  audit  trail  data. 

29  The  ScntryCATK  product  line  includes  the  user  interaction  surveil¬ 
lance  module  designed  by  Robert  A.  Clyde  and  implemented  with  assistance 
by  his  project  team  at  Clyde  Digital  Systems,  Orem,  Utah.  Some  14  suspi¬ 
cious  event  tests  tire  included  with  weighted  scoring  and  an  ordered  listing 
of  suspicious  users,  starting  with  those  determined  to  represent  the  highest 
risk  of  insider  threat  [8]. 

3u  With  respect  to  the  user- interaction  surveillance  now  in  the  field,  nu¬ 
merous  reports  have  been  received  *>/  the  vendor  of  misconduct  and  criminal 
activity  which  has  been  detected  using  same  on  Cl  and  C2  rated,  secure 
syterns  In  each  instance,  the  damage  to  the  sponsor  was  perpetrated  by 
insiders.  The  evidence  gathered  by  the  surveillance  technology  includes  the 
keystrokes  used  to  penetrate  the  access  controls,  together  with  the  corrc 
spondmg  system  responses 

See  for  example  footnotes  17  and  ?7  for  a  discussion  of  a  recent  case 
regarding  operating  system  alarms  and  the  traditional  audit  trails  provided 
with  operating  systems  now  in  wide  use 
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of  keystrokes  and  system  responses  is  essential  For  the  perpe¬ 
trator  of  damaging  activity  in  the  use  <»f  dangerously  privileged 
system  programs,  such  a  record  is  essential  fur  the  ultimate 
detection  of  th'  *r.ie  perpetrator  of  the  original  source  of  com 
promise.  For  example,  an  authorized  user,  experiencing  altered 
motivations,  may  give  certain  privileges  to  uunulttori/ed  per 
sons  in  ;*  collaboration  of  compromise  ami  exploitation. 

3.5.1  System  Surveillance  Selectivity 

In  order  to  effectively  enforce  a  broad  spectrum  of  policy 
requirements  for  system  surveillance  across  a  range  of  auto¬ 
mated  information  systems  of  varying  sensitivity,  the  surveil 
lance  technology  must  be  high  perfot mance.’2  and  it  must  be 
able  to  meet  a  demand  for  full- trace  capture  of  user  interactions, 
batch  stream  activities  and  system-events  when  required.  To 
deal  with  these  varying  requirements  and  w.th  what  may  lie  re¬ 
garded  in  some  eases  as  excessive  surveillan  e  data,  the  surveil¬ 
lance  technology  must  support  parameteri/.ition  for  selectivity 
of  ther  monitored  activities  and  of  the  data  captured  in  response 
to  the  governing  policy. 

For  some  cases  the  mandatory  capture  of  just  the  key¬ 
strokes  of  certain,  or  perhaps  all,  of  the  users  at  all  times  may 
be  a  suitable  parameterization  of  the  surveillance  system  for 
the  policy  in  force.’'3  At  other  sites,  there  may  be  a  policy  of 
blanket  monitoring.  There  are  numerous  sites  now  using  this 
monitoring  mode  with  user-ir.len.clion  surveillance. 

3.5.2  Secure  Master  Control 

In  order  to  assure  secure  access  to  a  master  control  module 
that  is  capable  <>f  parameterizing  the  execution  of  the  surveil¬ 
lance  system,  and  in  order  to  assure  the  ‘ainper  resistance  of 
the  surveillance*  system  itself,  two  techniques  are  recommended: 
1)  the  executable  image  of  the  master  control  program  can  be 
kept  encrypted  for  all  except  a  small  portion  of  its  user  interface 
logic,  and  2)  direct  access  to  the  surveillance  system  should  not 
be  given  tit  the  master  control  program,  just  as  it  is  not  given  to 
lilt*  operating  system,  the  trusted  computing  base  nr  any  other 
facility.  This  is  in  order  to  assure  the  independent  tamper- 
rcsistunoe  of  the  surveillance  system.**4  It  is  also  important 
that  the  execution  of  the  user-interface  logic  require  knowledge 
of  the  decryption  key  which  is  external  to  the  system. 

Tin  parameters  set  by  the  master  control  module  can  be 
encrypted  into  a  iablc  for  subsequent  decryption  by  the  surveil 
lance  system.  The  surveillance  system  itself  should  be  brought 

3?  One  of  th?  most  limiting  prnhlf-uis  witti  ’.ratiitionai  audit  trait  capa¬ 
bilities  currently  delivered  with  the  widely  used  operating  systems  as  a  s^t 
of  discretionary  functions  is  the  inordinate  burden  they  impose  on  the  pro¬ 
cessor.  The  consequence  is  a  persistent  conflict  u!  interest  in  demand  lot 
processor  resource  between  the  requ  rements  of  security  policy  fur  monitor¬ 
ing  and  the  intended  use  of  the  system  in  meeting  the  sponsor's  production 
objectives.  A  security  policy  will  not  be  viable  in  its  enforcement  unless  the 
technologies  requued  tor  that  enforcement  do  nut  conflict  with  trie  produc¬ 
tion  objectives  of  the  taiget  system. 

33  At  some  sites,  where  monitoring  activities  have  been  prait’ccd  with 
tiie  (united  traditional  auditing  techniques,  it  has  hern  suggested  thaf  con 
sidcrnble  value  could  be  obtained  from  monitoring  for  Keystrokes  only.  It  is 
suggested  by  some  that  this  is  sufficient  to  that  v«\sk  ol  successful  detection 
of  suspicious  events  by  automated  analysis  of  such  d  ita.  However,  when  the 
syulein  responses  are  i.«»t  leconU-d,  the  evidence  value  of  the  raw  curved 
lance  data  is  reduced  unrccovcrably.  (c.g.  It  is  difficult  to  determine  with 
certainty  what  look  place  when  system  responses  aie  not  captured.) 

See  fool note  22  for  a  discussion  on  tampe. -resistance  and  data  hiding, 
together  with  domain  independence  arid  layering.  Also,  see  section  1.3.1  1 
on  operational  assurance,  in  reference  jl; 


onto  tin-  computer  with  media  containing  an  executable  image 
that  is  encrypted  for  all  hut  a  small  portion  of  logic  that  pro 
vidcs  a  user  i  liter  fare  for  tin-  insertion  of  an  external  decrypt  ion 
kcv.  With  this  key  the  surveillance  system  decrypts,  loads  and 
starts  itself.  Thereafter,  it  decrypts  and  interrogates  the  pa  ■ 
ra meter  table  created  l>v  the  master  control  module.  Imr  added 
pmirei  ion  the  master  control  module  can  he  removed  from  the 
system  when  not  in  use.  In  addition,  tiie  external  decryption 
key  mcessary  to  run  the  master  control  module  should  he  dif¬ 
ferent  from  the  external  decryption  kty  necessary  to  bring  up 
the  surveillance  system.' 

3.G  Raw  Surveillance  Data 

Tiie  term  raw  s urvrilhmt'c  data  is  given  here  to  unal¬ 
tered  surveillance  data,  exactly  as  it  is  captured  and  originally 
recorded  by  the  surveillance  system.  Such  data  can  he  used 
to  support  a  number  of  objectives  in  the  management  of  auto 
mated  information  systems,  i  hose  of  particular  important  to 
a  discussion  of  insider  lineal  identification  systems  include  tiie 
following: 

•  Detection  of  suspicious  events  by  automated  anal¬ 
ysis 

•  Investigative  activities  for  perpetrator  identifica¬ 
tion  by  direct  inspection 

•  Evidence  gathering  for  case  development 

•  Fact -orient'. d '"’tienti  inn  of  a  surveillance  know! 
edge  base,  used  for  interactive,  expert  system 
idcntilicat.im  of  perpetrators 

•  Direct  inspection  for  detailed  nunessnfctil  of  known 
damage 

•  Recovery  of  damaged  data  structures 

•  Direct  inspection  and  analysis  of  attempted  pen¬ 
etrations  for  unexpected  weaknesses  in  the  art  ess 
controls 

It  may  he  concluded  that  the  generation  and  retention  of  raw 
surveillance  data  at  «  detailed  level  is  of  substantial  value. 

Indeed,  other  important  objectives  suggest  themselves,  and 
although  these  objecuves  he  outside  tin  scope  of  tins  paper, 
they  nevertheless  have  a  similar  dependence  on  detailed  raw 
surveillance  data  that  can  he  retained  for  subsequent  inspection 
and  use.  These  objectives  include  the  following: 

•  Automated  disaster  recovery  employ  ing  keystroke 
surveillance  data  gathered  hum  user  interactions 

•  Automated  disaster  recovery  employing  I/O  call 
surveillance  data 

•  In-depth  analysis  of  system  us*'  patterns  foi  ca¬ 
pacity  planning 

•  ln-depth  analysis  of  training  levels  and  adequacy 

•  Independent  auditing  ol  process  results  against 
those  expected  fr-an  policies  and  procedures  (e.g., 
financial  auditing) 

t  Enforcement  by  computer  of  labor- management 
policies  governing  harassment  of  users 

3:i  The  master  control  concept,  credited  to  Hubert  A.  Clyoe  at  Clyde  Dig 
it al  Systems,  has  been  siiccesslolly  implemented  by  members  of  tus  project 
350  team 


•  Employee  performance  ant!  productivity  measure¬ 
ment  (as  regulated  by  polity  and  employer  a^rcc 
incut) 

it  seems  dear  that  raw  surveillance  data  should  hr  retained, 
without  alteration,  in  order  to  oiler  subsequent  support  to  a 
widely  ranging  set  of  potentially  important  objectives  in  1  he 
management  of  antonu.lrd  information  systems.  I*  nrt  hernmre, 
on  the  matter  of  retention,  the  value  of  any  partieular  set  of 
surveillance  da* a  to  some  subsequent  demand  is  often  very  dif 
lit* nit  to  predict  at  the  time  t  he  surveillance  data  are  eapt  u red. 3,1 

3.0.1  Archiving 

Th  v  archiving  of  raw  surveillance  data  from  blanket  timni 
toring  with  user  inti  rartion  surveillance  is  now  comniouiy  prac¬ 
ticed  among  security  administrators  who  have  this  technology. 
They  are  not,  for  example,  trying  to  predict,  which  data  may  lie 
of  subsequent  value.  The  number  of  bytes  of  user  interac  tion 
surveillance  data  generated  from  user  to  user  can  vary  widely. 
However,  the  total  byte  counts  for  such  data  generated  oil  a 
given  system  in  a  day's  time  are  typicalh  quite  manageable.^7 

No  experience  is  yet  available  on  the  balance  between  de 
tail  and  quantity  of  dat.  in  the  areas  of  system-event  and 
batch  stream  surveillance.  However,  \\  seems  dear  that  batch 
stream  surveillance  need  not  be  more  than  a  modest  extension 
to  the  data  archiving  requirements  of  user-interaction  siirveil 
lance.  It  is  clearly  of  the  same  diameter,  in  both  eases,  re* 
dundant  sequences  of  identical  data,  together  with  large  con¬ 
tinuous  out]) iits  by  the  system  in  response*  to  the  user  or  the 
batch-command  stream,  can  simply  be  counted.  This  count 
information  can  replace  the  repetitive  information  in  the  raw 
surveillance  data  set  prior  to  archiving.  Simiiai  Lei  lumpics 
and  appropriate  selection  of  the  data  captured  by  system  event 
surveillance  need  to  he*  studied  further. 

3.6.2  Write-once  Media 

Optical  storage  technology  now  offers  a  number  of  compel 
itive  products  in  the-  single  and  multiple  gigabyte  range.  Such 
products  are  a  cost-effective  solution  to  the  archiving  require¬ 
ments  of  raw  surveillance  data.  The  write-once  feature  of  this 
technology  is  important  in  assuring  tamper  resistance  for  the 
surveillance  record  I  he  actual  medium  up  which  the  data  are 
written  is  removable  from  tin*  drive  mechanism.  1  his  triuuvablc 
medium,  which  is  about  the  size  of  a  traditional  long  playing 
phonograph  record,  goes  into  a  cartridge  one  inch  thick.  It  can 
be  packed  closely  ami  stored  in  quantity,  even  in  limited  vault 

^  Suspicious  events  depend  primarily  Tor  their  detection  on  the  analysis 
«'f  Ihr  raw  surveillance  data  set.  Detection  of  suspicious  event  usually 
occurs  at  a  time  which  is  considerably  later  than  the  event  itself  Once  a 
suspicious  event  is  detected,  an  investigation  of  raw  surveillance  data  into 
earlier  periods  is  always  of  value  in  establishing  t lie  chain  of  evidence  to  the 
ordinal  compromise. 

37  Data  taken  from  a  system  used  in  a  highly  interactive  mode  indicates 
an  avnage  of  about  2VJ.UUU  bytes  per  ny*r  per  day  I  Ins  includes  clerical, 
technical  support,  technical  writing  and  development  personnel.  These  b  an 
kel  monitoring  results  are  believed  to  be  burly  typical  of  such  en  * ir«inmc»i's. 
However,  the  amount  of  raw  surveillance  data  captured  in  the  blanket  mode 
tan  vary  widely,  depending  on  the  nature  of  uber  activities  on  a  given  system. 

38  The  surveillance  of  I/O  call  activity  could  heroin**  burdensome.  How- 
ever,  in  most  cases  it  would  seem  adequate  to  capture  only  a  small  portion 
of  read  request  output  without  losing  the  ability  to  characterize  accurately 
the  events  taking  place.  On  the  other  hand,  if  I/O  rail  surveillance  »s  to 
he  used  for  automated  disaster  recovery,  then  all  write  activity  to  the  d-.ta 
structures  requiring  this  level  of  protection  Would  have  to  be  captured. 


spate.  Hus  medium  is  not  subject  to  damage  front  elect rir  or 
magnetic  field.**.  It  is  expected  to  be*  stable  over  long  periods  of 
time,  with  a  life  «»f  at  least  |  ()  years. 

Write  once  storage  merlin  require  speri.il  l  ie  I/O  handling 
tlt.rt  will  not  attempt  to  rewrite  portions  of  the  medium.  Such  a 
file  handler  must  deal  with  the  differing  requirements  for  merlin 
faults  a  iir  I  rend  access  of  this  cl  nss  of  storage,  m  comparison  \\  it  h 
the  requirements  ol  the  traditional  magnetic  disk  technology. 

I  he  file*  handler  is  suppl.er!  m  some  ra.ses  by  the  manufacturer  of 
the  optical  storage  drive,  h  de  handling  js  also  provided  wit  h  the 
surveillance  system  product  in  order  to  support  the  advantage 
of  tamper- resistance  on  traditional  media,  where  write-one*-  can 
also  he  enforced. 

3.G.2.1  Cost  Effectiveness 

I  he*  e-fist  pe-  byte  of  write-once  media  is  consistent  with 
that  of  conventional*  magnet  ic-tape  storage  media  for  data 
archiving.  I  he  cost  <»i  l  he  drive  is  consider;!  hi  v  less  per  bvle 
than  that  ol  tap**  orierped  drives.19  As  for  si/e,  one  optical 
storage  drive  currently  offered  ran  i»e  fitted  into  5.25  inches  of 
standard  elec  tronic*  rac  k  spare. 1,1 

In  addition  to  tin-  cost  advantage  of  optical  storage  in 
archiiing.  this  technology  also  olFers  a  lost  ellective  alterna¬ 
tive  to  traditional  on-line  storage  for  random  read-access  to 
larKe  segments  .if  ran  surveillance  data.  It  is  expected  that 
the  costs  or  optical  suaage  will  decline  with  time,  maintaining 
a  continuing  advantage  over  magnetic  media  where  write-once 
is  .cquired.  lor  magnetic  media,  this  write  once  requirement 
rep i events  an  additional  cost  for  c-nforcement. 

I  he  peculiar  <  n'nl" nation  of  cost  relationships  nirrcntlv  of 
fereii  by  optica!  storage  and  the  expectation  of  dec  lining  costs 
are  most  encouraging.  Tlusc  benefits  come  at  a  time  when  it 
is  becoming  more  important  to  archive  sullieient  quantities  of 
raw  surveillance  data  to  successfully  support  the  objectives  of 
insider  threat  identification  systems.  Within  reasonable,  bal 
aimed  cost  constraints,  it  now  appears  that  such  objectives  can 
be  .successfully  addressed  through  the  support  of  archived,  full 
system,  raw  surveillance  data,  where  appropriate  constraints 
arc  imposed  on  the  selection  of  the  system  events  monitored 
and  the  quantity  of  such  data  captured. 

3.7  Knowledge  Uns(! 

'I  lie  knowledge  base  'hat  supports  the  expert  system  in  the 
analysis  for  suspicions  nulls  is  described  here  as  a  surveillance 
Knowledge  base.  The  surveillance  knowledge  base  has  a  domain 
that  includes  a  m  tuber  of  fact  contributions  called  fact  sets  and 
a  number  of  rule  contributions  called  ril/e  sets. 

39  ,. 

Inc  I  mrpurs  baser  System  uptkal  disk  stoinge  subsystem  is  uun. 
pared  here  with  Higit.,1  Kquipment  Corporation  Vl'KAn  magnetic  tape  drive 
using  a  streamer  tape  cartridge  The  Percept  its  optical  disk  carl  ridge  is  c.Jr. 
r.  ntly  pot  e,l  at  $u  ‘.MS  per  me-g.ilnte  and  the  Digital  I  K5tl  '.ape  cartridge  is 
priced  .  ur.-ently  at  Si)  Huh  ner  megalivlr.  F„r  the  drives,  I'erceptics  is  p,  iced 
at  $12.50  per  megabyte  and  Digital  is  at  $35.79  per  megabyte. 

111  lhr  Prrceptns  optical  disk  cartridge  inr.isiiies2r.mm  (I  u,  )  i„  height. 

3311,11,1,  (13m)  in  Width  and  334mm  ( 13. 14  in.)  in  depth 
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3.7.1  Fact-based  Knowledge 


The  fact -based  portion  «»f  the  surveillance  knowledge  base 
include!!  I  lie  following  distinct  sets  of  farts: 

•  .Siirm'/Zarire  fad  set  -derived  from  raw  survei! 
lance  data 

•  /■’.vliTfia/  fort -set  external  to  the  system,  includ 
ing  facts  about  changes  in  user  status,  new  users 
and  terminated  users 

•  Supporting  fad -set  image  facts,  system  library 
facts,  access  authorization  fads,  and  facts  from 
suspicious  event  test  modules 

•  I'mlilc  fad  -sd  -  the  fact -oriented  portion  of  the 
surveillance  knowledge  base  contained  in  each  of 
a  number  of  profile  st  rue  i  ures  for  suspicious  event 
testing. 

3.7. 1.1  Primary  Data  It  educt  ion 

A  variety  of  data  extraction  and  structuring  activities  may 
h<*  applied  to  the  raw  surveillance  data  may  be  found  useful, 
depending  on  the  system  management  objectives.  However,  for 
support  of  the  objectives  of  aii  insider  threat  identification  sys¬ 
tem,  only  one  such  activity  is  considered  here.  I  lie  intention 
of  this  activity  is  to  create  an  appropriately  structured,  fact- 
oriented  surveillance  knowledge  base  by  suitable  extraction  from 
tin*  raw  surveillance  data.  The  extraction  process  should  invoke 
a  set  of  rules  that  serve  to  mediate  the  exclusion  of  extraneous 
data  in  the  generation  of  a  reduced  data  set.  I  his  primary  set 
of  i  ides  unis',  be  based  on  expert  knowledge  about  which  data 
arc  relatively  safe  to  ignore. 

3. 7. 1.2  Surveillance  Fart-set 

The  reduced  data  are  io  be  used  in  constructing  the  surveil¬ 
lance  fact-set  portion  of  the  surveillance  knowledge  base.  I  hese 
facts  aic  extracted  from  the  raw  surveillance  data  captured  over 
a  specified  period  of  time.  The  construction  of  this  contribution 
to  the  surveillance  knowledge  base  is  governed  by  the  base-level 
knowledge  engineering  logic  in  the  expert  system.  1  his  base- 
level  knowledge  engineering  is  limited  to  that  which  can  be  in¬ 
dependent  of  a  given  system.  The  fundamental  element  of  this 
fact -set  is  called  a  si/rveilia/ice  record. 

The  surveillance  record  is  an  access  oriented  structure  of 
the  following  form: 

(subject,  object,  access-attributes) 

The  access- attributes  include  the  following: 

•  Surveillance  m«  du/t  source  a  surveillance  mod¬ 
ule  that  captures  the  data  (this  is  essential  to  each 
surveillance  record) 

•  Action  the  type  of  operation  performed  by  the 
subject  on  the  object 

•  /fesoui  cc  usage  such  information  as  the  number 
of  reads,  writes,  lines  printed,  CPU  resource  used, 

1/0  resource  used,  etc. 

•  Dote  and  time  .stamping  the  date  and  time  of 
the  access  (this  is  an  essential  data  item  in  each 
surveillance  record) 

•  Keystrokes  keystrokes  (for  user-interaction  sur¬ 
veillance)  and  pseudo  keystrokes  (for  batchstrcam 


surveillance),  included  in  the  surveillance  record 
as  required 

•  Snlisetjueiit  nrhitu  the  response  of  ihe  system  to 
mi  access:  that  is.  tin*  action  or  condition  that  re 
Stdted  from  the  access,  and  ;>s  much  of  t  he  out  put 
data  (information  sent  lo  a  terminal  or  other  out 
pul  device )  as  required  (the  action  or  con  (lit  •«  m  is 
essential  data) 

I  Ills  structure  can  lie  chiiract enzed  as  an  /i  tunic,  v  here 
u  varies  with  the  surveillance  module  on  which  the  surveillance 
record  data  depend. 

3.7. 1.3  External  Fart-set. 

The  external  fact  set  is  a  coin  cl  ion  of  facts  external  to 
the  system  under  sm  veil  lance  that  may  cun  tribute  to  tin*  fact 
oriented  portion  of  tin*  surveillance  knowledge  base*.  Such  facts 
may  include  in  fur  mat  ion  a  I  unit  I  rrininat  mu  of  employ  men1 :  new 
users;  Users  uitji  changed  statu-.,  including  pi n/iiotams.  demo 
tions  and  changed  an ( luu i/al ions;  and  information  that  may 
characterize  motivations.  1  his  information  may  be  updated  t<» 
(lie  surveillance  knowledge  base  from  lime  to  time  as  required. 

3. 7. 1.4  Supporting  Fact-set. 

The  supporting  fart  m'  contains  ot  her  t  vpes  of  fact  orient 
ed  knowledge  that  are  included  in  the  surveillani e  knowledge 
base.  The  access  authorization  tables  are  one  such  type  nf  sup 
porting  fads.  These  tables  may  take  a  variety  of  forms  at  vary¬ 
ing  levels  of  detail,  depending  on  the  system  and  the  security 
policy  to  be  enforced.  These  are  the  data  used  by  the  trusted 
computing  base  to  determine  if  an  access  request  is  authorized. 
A  general  form  of  these  tables  is  discussed  elsewhere  (j..  In  this 
general  form,  the  access  of  ;»  specific  objee1  by  a  specific  sub 
jert  is  supported.  A  copy- of  this  class  of  fact  oriented  knowledge 
(as  independently  secured  data,  extracted  on  a  periodic  basis) 
is  a  necessary  complement  to  the  surveillance  knowledge  base 
in  some  cases.  This  fact -set  includes  the  variance  from  average 
rates  of  change  and  related  measurement*. 

Other  supporting  contributions  to  this  fact  set  include 
changes  in  the  operating  system  image  arid  the  system  library 
image.  Of  interest,  is  the  detail  of  t lie  change,  togel her  with  the 
variance  from  average  rates  of  change  over  a  period  of  time. 

In  addition,  there  are  supporting  facts  associated  with  the 
suspicious  event  test  modules  and  their  modification  and  exten¬ 
sion. 

3. 7.1. b  Profile  Fart-set 

The  concept  of  a  prn/j/e  comes  from  the  need  for  a  eon 
struct  that  can  represent  a  norm  for  a  specific  activity  on  tin- 
target  system.  It  lias  grown  out  of  the  statistical  analysis  ap 
proach  to  suspicious  event  testing.  It  is  used  here  as  a:i  ex 
tended  construct  for  supporting  both  statistically-oriented  ami 
inference-oriented  suspicious  event  testing.  These  constructs 
contain  activity-dependent  facts  that  contribute  to  the  knowl¬ 
edge  base,  both  for  pattern  matching  and  for  detection  by  in 
fererne.  This  contribution  is  the  pro/ile  fact-set.  Facts  derived 
during  the  course  of  analysis  are  also  included. 
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3.7.2  Ruhvliftsetl  Knuwlodgo 

Thr  nilt* -orirnl rtl  portion  «»f  ilu-  mi rvcillanro  knowledge 
li;*.sr  i li'pc- ii i!.-.  t  riliriill y  nil  cxprrt  kimwloclgt  of  system  rniupro 
nnsing  ! i*rli ii i c| iirs  and  Hindis  of  security  policy  dotation.  A 
rule  is  ilia i ac  teri/eil  as  a  fundamental  structural  element  in  the 
surveillance  knowledge  base.  It  lias  the  following  form: 

If  (proposition)  then  (action) 

When  the  proposition  tests  true,  tlu*  action  is  performed. 
Ksta lihslii ng  a  new  fact  is  an  important  class  of  action.  In  gen¬ 
eral,  an  iufcreuce  oi  ienled  suspicions  event  lest  is  a  set  of  one 
or  more  rules.  Some  propositions  and  actions  are  fixed,  inde 
pendent  of  the  daily  dynamics  of  a  system  or  related  external 
events.  Other  propositions  and  actions  may  vary. 

Some  parameters  in  propositions  and  actions  may  be  an 
tomaticaliy  changed  by  an  update  to  the  fact -oriented  portion 
of  the  surveillance  knowledge  base.  Others  may  be  changer!.  <>r 
new  rules  created,  depending  on  1 1n*  action  of  a  previous  rule. 
It  is  also  important  that  some  of  these  parnmcU  rs  be  accessible 
to  an  investigative  expert.  'I  lu*  parameterization  of  some  sus 
picious  event  tests  is  essential  to  an  investigation  in  which  tin* 
expert  system  is  used  by  trained  professionals  in  an  interactive 
mode. 

3.7.2. 1  Surveillance  Rule-set 

The  survrilJuin  rule-set  is  associated  with  the  surveillance 
fact-set.  The  construction  of  this  contribution  to  the  surveil¬ 
lance  knowledge  base  is  governed  by  the  base-level  knowledge 
engi  nevi itig  logic  m  the  expert  system.  I  ins  rule-set  is  limited 
to  just  those  rules  that  can  be  independent  of  a  given  system. 

3. 7. 2. 2  External  Rule-set 

The  externa/  rule-set  is  associated  with  the  external  fact 
set.  A  domain  expert  is  to  be  supported  with  tools  for  the  mod¬ 
ification  and  extension  of  the  rules  in  this  set.41  These  rules  are 
also  to  be  parameterized  where  possible  to  support  the  domain 
expert  in  easily  performing  various  investigative  experiments. 
The  parameter  changes  must  he  simple  to  understand  in  their 
effect  and  must  be  straightforward  to  perform. 

3. 7. 2. 3  Supporting  Ruh  •-set 

'The  supporting  ni/r-M,l  is  associated  with  the  supporting 
fact -set.  As  with  the  external  rule-set,  a  domain  expert  is  to 
supported  with  tools  f« >r  the  modification  and  extension  of 
the  rules  in  the  set.  And  again,  the  rules  must  be  parame¬ 
terized,  where  possible,  to  permit  investigation.  The  rules  are 
constructed  to  address  changes  in  use  norms  and  to  identify 
suspicious  activity  by  inference  when  there  have  been  changes 
in  user  status. 

3.7. 2.4  Profile  Rule-set 

'I  lu*  profile  rule-set  is  associated  with  the  profile  fact  set.  It 
includes  activity  dependent  rules,  together  with  rules  that  may 
be  established  by  the  expert  system  and  inserted  during  the 
course  of  analysis.  The  potential  for  such  inserted  rules  must 
exist  throughout  the  expert  system. 

41  Donald  A.  Waterman  [  I  1]  characterizes  a  domain  expert  as:  "A  pprson 
who,  through  years  of  training  and  experience,  has  becume  extremely  proh 
cient  at  problem  solving  in  the  particular  domain."  The  domain  here  is  that 
of  expertise  in  system-compromising  and  penetration  techniques  relative  l«» 
spec i tie  security  policy  and  system  characteristics. 


3.7.3  Profile  Set 

The  |>n»lilo  set  consists  of  a  number  of  profile  structures. 
I  be  profile  structure  used  here  is  an  extension  # -.f  that  described 
by  Denning  3  1  < »  aceummodair  the  advaiil  ages  of  surveillance 
record  data.  1  he  advantage  of  this  type  of  data  is  the  ability 
to  look  nmrc  elosel\  at  use  patterns.  The  prof’le  structure  is 
described  here  as  a  profile  record.  The  structure  of  a  profile 
record  is  of  t  his  form : 

(dependent  components,  independent  components) 

The  following  components  of  tlu-  profile  record  depend  on 
tin*  subject  and  object  in  a  given  access  relationship: 

•  Subject  pattern  the  pattern  to  match  with  the 
subject  siring  in  the  surveillance  record 

•  Object  pattern  the  pattern  to  match  with  the 
object  string  in  the  surveillance  record 

•  f  act  set  includes  the  results  of  one  or  more  sta¬ 
tistical  lesls,  tlu*  parameters  for  the  statistical 
model  and  some  profile- record  dependent  facts  as 
required 

•  /fit /e-set  includes  certain  profile-record  depen¬ 
dent  rules  as  required 

a  Inference  I. ng'n  is  used  in  conjunction  with  pro 
file-record  independent  knowledge  as  part  of  the 
expert  system 

The  following  components  are  independent  of  the  subject 
or  object  it;  a  given  access  relationship: 

9  \ariable  name  —uniquely  identifies  the  profile  re¬ 
cord  for  a  given  subject  pattern  and  object  pat¬ 
tern 

9  Surveillance  nunlulr  pattern  the  pattern  that 
matches  with  the  surveillance  module  identifica¬ 
tion  string  in  a  surveillance  record 

•  .-let  inn  pattern  the  pattern  to  match  with  the 
action  string  in  a  surveillance  record 

•  Resource  usage  pattern  the  pattern  to  match 
with  resource  usage  data  in  a  surveillance  record 

9  /Vr/ocf  pattern  the  pattern  matched  to  the  dur- 
ation-of  actum  information  as  derived  from  the 
date  and  time  data  in  a  surveillance  record 

•  Keystroke  pattern  the  pattern  to  match  to  key¬ 
stroke  data  in  a  surveillance  record 

9  Subsequent  action  pattern  the  pattern  to  match 
with  subsequent  action  data  in  a  surveillance  rec¬ 
ord 

9  /  act-set  suspicions  event  test  to  be  used  and  cer¬ 
tain  profile- record  independent  fads  that  result 
from  inference  or  statistical  analysis  (this  fact-set 
also  includes  the  threshold  parameters  used  in  de¬ 
termining  suspicious  activity  from  the  results  of  a 
statistical  test) 

»  Rule  set  includes  certain  profile-record  indepen¬ 
dent  rules  resulting  front  inference  or  statistical 
analysis 

Each  profile  record  represents  a  specific  profile  defined 
uniquely  by  the  variable  name,  subjec  t  pattern  and  object  pat¬ 
tern.  The  general  constructs  for  specifying  a  pattern  ,11  include 
the  following: 
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«  Character  string 

®  Wildcard  matching  for  any  string 

•  Match  for  any  numeric  string 

«  Match  for  any  string  in  a  given  list 

•  The  string  matched  with  a  given  string  is  to  ho 
associated  with  a  given  name 

•  Match  pattern  l  followed  1)3'  pattern  2 

•  Match  pattern  1  or  pattern  2 

•  Match  pattern  1  and  pattern  2 

•  Match  for  all  but  the  pattern 

These  constructs  are  used  to  support  a  variety  of  statistical 
models.  A  number  of  such  models  are  discussed  by  Denning  \X. 
Th  esc  models  are  used  to  perform  statistically  oriented  suspi¬ 
cious  event  testing  by  matching  profile  record  patterns  against 
selected  surveillance  records.  The  results  are  acted  upon  by 
rules  for  determining  abnormality  (suspicion)  based  on  thresh 
old  and  variance  parameters. 

The  results  of  statistical  analysis  for  certain  profile*  may  be 
used  to  construct  new  facts  and  rules.  These  are  placed  in  the 
independent  fact-  and  rule-set  components  of  the  profile  record 
and  become  part  of  the  surveillance  knowledge  base  on  which 
the  inference-oriented  suspicious  event  tests  operate. 

3.7.3. 1  Profile  Record  Classes 

A  profile  record  class  is  defined  as  one  of  a  number  of  com¬ 
binations  of  subject  group  and  object  group  pairs.  For  example, 
there  is  a  profile  record  class  for  actions  performed  by  a  group 
of  one  subject  aggregated  over  all  objects  in  a  group  that  forms 
a  class.  Suspicious  event  tests  are  performed  on  these  aggrega¬ 
tions  of  profile  records.  Such  tests  may  he  called  class  tests.42 

3.7.3  2  System  Profile  Set 

A  system  profile  set  should  include  a  list  of  authorized  pro 
grams  from  the  certified  system  library,  together  with  the  fol¬ 
lowing  use  attributes:  1)  use  frequency,  2)  typical  duration,  3) 
typical  times  of  clay  used,  4)  seasonal  or  periodic  use,  and  5) 
overall  system  burden.  The  typical  system  loading  characteris¬ 
tics,  including  such  information  as  job  mix  and  peripheral  use, 
may  also  be  useful.  Daily,  weekly,  monthly  and  seasonal  system 
loading  could  be  considered.  Data  movement  and  storage  on  the 
system  could  be  characterized  with  current  volumes,  and  with 
rates  of  change  and  variance.  'Phis  should  include  movement 
into  and  out  of  the  system. 

No  work  in  the  identification  of  insider  threat  is  know  to 
have  been  reported  for  this  type  of  profile  tabic.  It  is  likely 
that  such  information  may  nevertheless  enjoy  some  use  by  a 
few  government  and  military  groups  in  identifying  abnormal  use 
patterns.  System  profile  tables  can  clearly  make  a  contribution 
to  the  fact-oriented  portion  of  a  surveillance  knowledge  base  for 
expert  system  analysis. 

^  A  brief  description  is  given  by  Denning  for  each  generic  class  of  profile 
record  aggiegates  (3j. 


3. 7. 3.3  Program  Profile  Set 

A  program  profile  set  should  include  such  information  as 
files  accessed,  processes  i ui tinted  and  privileged  system  services 
requested.  Typical  data  volumes  and  rates  may  also  be  in¬ 
cluded.  In  addition,  data  may  be  included  for  time  and  fre¬ 
quency  of  use.  Attributes  for  I/O  and  compute  process  ratios 
may  be  useful,  together  with  any  special  start  up  or  termination 
restrictions. 

In  some  cases  policy  requires  a  bit  image  checking  of  the 
entire  system  library  against  an  independently  secured  copy  of 
same.  Such  periodic  testing  can  provide  assn  ranee  against  per 
manent  loss  of  program  certification  from  compromise  due  to 
an  insider  act,  malicious  or  otherwise,  or  due  to  spontaneous 
media  faults.  This  technique  may  he  list'd  to  “disinfect”  a  sys¬ 
tem  library  under  attack  [IK,.  This  practice  will  not,  however, 
offer  protection  against  a  system  penetration  where  a  program 
is  altered  briefly  for  certain  inappropriate  objectives  and  then 
returned  to  its  original  certified  condition. 

3. 7. 3. 4  User  Profile  Set 

The  user  profile  set  should  include  a  characterization  of 
programs  typically  accessed  and  their  frequency  of  use.  In  some 
cases,  information  on  time  of  day  normally  used  or  on  other 
time-use  habits  may  lie  important.  Similarly,  certain  comple¬ 
mentary  information  about  files  accessed  outside*  of  fixed,  certi¬ 
fied  procedures  (e.g.,  with  an  editor)  should  br  included.  Also, 
habits  in  the  use  of  various  system  services  should  be  charac¬ 
terized. 

Information  about  typical  data  volumes  processed  by  the 
user  under  different  circumstances  and  with  different  selected 
programs  should  be  considered.  In  some  cases  it  may  be  nec¬ 
essary  to  characterize  use  patterns  at  a  keystroke  level,  partic¬ 
ularly  in  the  use  of  dangerously  privileged  programs  and  for 
critically  sensitive  files. 

The  inclusion  of  certain  privileges  and  authorizations  that 
may  be  complementary  to  specific  object  access  rights  found  in 
the  access  authorization  tables  may  also  be  required  by  some 
types  of  security  policies.  For  example,  a  user  may  be  autho¬ 
rized  to  change  certain  data  only  in  specific  ways. 

Some  activity  profiles  of  particular  interest  may  be  found 
described  by  Denning  |3j.  Others  are  listed  in  outline  form  in 
[15).  An  exhaustive  list  is  represented  by  all  objects  managed 
by  the  automated  information  system  considered  against  file 
possible  actions  with  those  objects.  For  example,  read,  write, 
change,  compute,  execute  and  move  or  copy. 

3.8  Expert  System  Considerations 

It  is  recommended  that  the  expert  system  for  analysis  he 
constructed  around  a  concept  of  generic  test  rnodu/es.  For  con¬ 
venience  three  generically  distinct  test  classifications  arc  identi¬ 
fied  to  span  the  domain  of  possible  suspicious  event  tests.  They 
are  the  following: 

•  System  Test  Module  includes  suspicious  event 
tests  that  consider  system  activity  as  a  whole. 

•  Program  Test  Module  includes  suspicious  event 
tests  that  consider  program  activity. 

«  User  Test  Modrle  includes  suspicious  event  tests 
that  consider  user  activity 
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Kadi  module  generally  consists  of  some  arbitrary  number 
of  test  submodules,  depending  on  the  security  requirements  of 
a  given  system.  'These  submodules  operate  upon  the  siirveil 
la  nee  knowledge  base  as  components  of  the  expert  system.  In 
general,  the  submodules  relate  to  profile  records  and  particular 
aggregates  of  profile  records. 

'The  expect  system  analysis  for  suspit  ions  events  must  be 
able  to  produce  a  trace  of  I  be  inference  chain  that  leads  to 
tlu*  identification  nT  an  asserted  suspicious  activity.  Ifolli  al 
goriUutiic  and  heuristic  rules  must  be  supported.  Suspicious 
events  are  to  be  weighted  by  the  expert  system  and  aggregated 
to  characterize  suspicious  activities.  'These  suspicious  activities 
are  given  a  criticality  score,  based  «>u  the  weighted  scoring  of  the 
supporting  events.  An  «»rd  red  listing  is  to  be  produced  with 
the  highest  scoring  suspicious  events  ocriiring  first.  Supporting 
documentation  is  to  be  provided  on  demand  at  descending  lev 
els  of  increasing  detail.  For  example,  an  investigator  must  be 
able  to  request  the  presentation  of  a  Imre  of  the  inference  (bain 
for  a  specified  suspicious  activity.  Ollier  levels  of  detail  include 
the  surveillance  file  names,  excerpts  from  the  raw  surveillance 
data,  and  finally,  the  raw  surveillance  data  itself. 

3.8.1  Code  Generator  Support 

The  submodules  are  to  be  constructed  by  fully  automated 
code  generation.  Such  generators  are  themselves  a  type  of  spe¬ 
cial  expert  system.  In  this  case  there  is  a  special  knowledge 
base  that  would  correspond  to  each  generic  test  module. 

The  user  of  the  code  generator  would  be  a  domain  expert, 
where  the  expertise  is  in  the  field  of  inside  r  threat  identification. 
"This  expert  would  be  supported  by  the  emir  generator  in  spec 
ifying  suspicious  event  tests  for  each  generic  test  module.  This 
type  of  capability  requires  a  computable  specification  language 
within  the  framework  of  an  expert  system  based  code  generator 
This  is  a  new  field  of  technology  that  is  attracting  substantial 
attention  with  products  that  are  beginning  to  stabilize.  13 

The  generation  of  test,  submodules  ran  he  characterized 
as  the  creation  of  the  site  varial.de  portion  of  the  rule-based 
knowledge  in  the  expert  system.  'This  addresses  the  issue  of 
cost  effectiveness  where  the  set  of  suspicious  event  tests  and 
their  individual  characteristics  may  have  to  vary  substantially 
from  site  to  site,  depending  oil  policy  and  circumstances. 

The  code  generator  contributes  a  fact  set  and  a  rule-set  to 
the  corresponding  supporting  fact-  and  rule-sets  of  the  surveil¬ 
lance  knowledge  base.  This  includes  the  code  generator’s 
paradigm  for  each  generic  test  module.  The  code  generator 
in  turn  shares  the  surveillance  knowledge  base  with  the  expert 
system  for  analysis. 

'Templates  of  all  suspicious  event  test  submodules  are  to  he 
included  with  the  code  generator  as  the  starting  point  for  the 
domain  expert  at  each  site.  This  is  the  tool  that  supports  the 
domain  expert  in  creating,  modifying  and  extending  suspicious 

Computer-aided  Software  Kiij;i nreri ii; .  is  now  an  active  held  in  t lie  pri 
vatc  sci  lor  fm  product  devrlopmt-iiL.  Some  ol  these  products  arc  beginning 
to  fill  Mil  Ilic  historical  promise  of  fifth  generation  language .  The  first  Inter 
national  Workshop  on  Computer  aided  Software  Knginceriug,  called  CASK 
*87,  was  held  in  Boston  late  in  May,  1987.  A  number  ol  leading-edge  coiitnb 
utors  shared  position  papers  and  current  terhnic.il  status  in  a  professional 
workshop  environment.  The  proceedings  are  available.  The  more  salient 
inntrri.il  is  to  be  published  by  the  IKKK.  Clyde  Digital  Systems  has  nil 
vamed  a  product  in  the  field  which  is  believed  to  he  capable  of  addressing 
the  pioblciu  of  supporting  a  domain  expert  in  transforming  the  generic  Lest 
shells  into  specialized,  suspicions  event  tests  by  fully  automated  program 
generation. 


event  tests.  'This  approach  will  contribute  high  efficiencies  and 
low  costs  to  the  customization  and  production  of  sib-  specific 
tost  submodules.  The  type  of  expert  system  based  code  gen 
erutor  under  discussion  here  makes  it  particularly  easy  for  the 
domain  expert  to  re-enter  a  specification  session,  make  changes 
and  regelieiute  correct  code.  11 

[t  appears  reasonable  in  suggest  that  certain  of  the  knowl¬ 
edge  engineering  width  relates  to  the  higher  level  structuring 
of  the  fact -oriented  portion  of  the  surveillance  knowledge  base 
could  he  programmed  using  I  he  code  generator.'15  Such  struc¬ 
turing  would  deal  with  creating  relationships  among  the  ele¬ 
mental  structures  that  support  a  particular  suspicions  event 
test  submodule. 

Some  suspicions  event  tests  require  higher  level  structures 
in  the  surveillance  knowledge  base.  The  log*e  responsible  for 
this  task  could  come  from  the  sile-depeudent  knowledge  engi¬ 
neering.  This  would  be  performed  by  the  code  generator  in 
conjunction  with  the  generation  of  site  specific  suspicious  evenl 
tests. 

3.9  Maintenance 

'The  maintenance  of  the  suspicious  event  submodules  is  pro¬ 
vided  by  the  code  generator.  U  is  intended  that  persons  of  less 
expertise  than  the  domain  expert  be  qualified  to  use  the  code 
generator  for  maintenance  of  the  test  submodules. 

3.9.1  Change  of  User  Status 

A  change  of  user  status  will  (Tien  require  an  adjustment  to 
a  number  of  profile  iccoids  involving  the  user  as  the  subject. 
It  is  intended  that  this  he  performed  by  the  system  security 
administrator.  The  paradigms  buili  into  1  he  i ode  generatm  for 
suspicious  event  testing  are  to  largely  automate  the  task  of  mak¬ 
ing  profile  record  changes  based  on  a  few  simple  designations  of 
status  change. 

3.9.2  New  Users 

The  insertion  of  profile  records  corresponding  with  a  new 
user  is  to  he  performed  by  the  system  security  administrator. 
This  is  to  he  a  highly  automated  task  using  typical  profile  record 
templates. 

4.  Conclusions 

Surveillance  technology  is  the  essential  foundation  of  an  in¬ 
sider  threat  identification  system.  The  experience  front  the  field 
for  user  interaction  surveillance  encourages  the  belief  that  full- 
system  surveillance  can  be  achieved  cost  eflectivcly  with  high 
performance  products  that  do  not  represent  an  excessive  burden 
to  the  system  under  surveillance.  Acceptance  of  the  snrvedlance 
concept  has  been  expanding  substantially  in  the  private  sector, 
with  growing  interest  and  installed  sites  throughout  the  Navy 

Substantial  work  lias  been  dour  at  (’iyrir  Digit. il  S\ stems  by  Stephen 
\V-  Clyde  and  liio  prujci  l  Irani  under  the  dire*  tiun  of  *  be  ,iiil in»r ,  on  expert 
system  based,  fully  automated  code  generation.  The  prudiut,  PruCODF, 
now  in  the  field,  support.}  changes  to  a  specification  ami  regeneration  of  code 
with  pan.icol.ir  ease. 

Current  experience  with  fully  automated  code  generation  and  a  com¬ 
putable  high  level  .pecifuation  interface  encourages  the  bcht-l  'hut  al  leas’ 
a  portion  ol  the  knowledge  engineering  can  be  done,  site -spec itu ally,  by  lb" 
domain  expert  This  is  the  know  ledge  engineering  that  would  create  code 
for  budding  rela’  Kinships  among  the  structural  elements  of  t  he  surveillance 
kn<»v.-lrdgr  base  in  support  of  any  g»ven  siispou  us  ev-nt  ipsl 
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and  certain  government  agencies.  The  technology  and  price 
performance  of  the  kind  of  on-line  storage  and  archiving  media 
repaired  In  support,  the  surveillance  concept  are  now  entering 
the  market. 

M  ik  h  work  needs  to  he  done  to  improve  and  extend  the 
technologies  of  analysis  for  suspicious  event.,.  The  work  of  Dm 
ning  jit!  at  SKI  suggests  an  even  more  successful  application  of 
statistical  analysis  techniques  to  full  system  surveillance  data. 
It  seems  dear  that  the  expert  system  approach  can  be  fruit 
ful,  particularly  as  it  is  extended  to  perform  inference-oriented 
suspicious  event  testing,  (’ode  generating  technologies  are  now 
stabilizing  in  the  field  can  contribute  substantially  to  the  cost 
effectiveness  of  creating  and  maintaining  s:lo  specific  suspicious 
event  test  submodules 

Work  needs  to  be  done  in  characterizing  the  structure  and 
detailed  objectives  of  the  last  three  components  of  an  insider 
threat  identification  system.  It  is  clear,  however,  that  evi 
deuce  gathering,  damage  assessment  and  recovery  support  de 
pend  critically  on  detailed  surveillance  data  at  a  key>t  r«»k«*  level. 

*  The  government  can  benefit  by  offering  the  kind  of  support 
and  encouragement  to  this  new  discipline  that  will  send  a  dear 
signal  to  private capitot  that  there  will  be  a  market  that  justifies 
investment. 
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INTHODUCTIOS 

In  January  )975,^  a  j o int-serv ices  High 
Order  Language  Working  Group  (HOLWG)  was 
established  by  the  U.S.  Department  of  Defense 
(D<  0)  to  identify  requirements  for  DoD  high 
or*  3c  languages,  evaluate  existing  languages 
against  these  requirements,  and  recommend  the 
adoption  or  implementation  of  a  minimal  set  of 
programming  languages.  The  HOLWG  developed 
the  following  series  of  increasingly-refined 
requirements  documents:  STRAWMAN,  April  1975; 
WOODENMAN,  August  1975;  TINMAN,  January  1976; 
IRONMAN,  January  1977;  and  STEELMAN,  June 
1978.  All  of  these  documents  went  through  a 
wide  range  of  reviews  from  the  DoD,  academic, 
and  industrial  communities.  A  study  was 
undertaken,  with  the  release  of  TINMAN,  to 
determine  if  any  existing  language(s)  met  the 
requirements.  While  it  determined  that  no 
language  or  set  of  languages  satisfied  the 
requirements,  the  study  indicated  the 
feasibility  of  developing  a  new  language  to 
meet  the  requirements. 

2 

In  April  1977,  an  international  design 
competition  was  launched,  based  on  the  IRONMAN 
requirements.  The  language  design  was 
completed  ir.  Kay  1979.  A  testing  phase 
commenced  and  final  revisions  were  made  to  the 
Ada  language.  Ada  was  accepted  as  a  Military 
Standard  (MIL-STD)  in  December  1980  and 
established  as  an  ANSI  standard  on  17  February 
1983. 

The  HOLWG  Chairman,  Lt  Col  William 
Whitaker  (USAF,  now  retired),  realized  the 
need,  during  the  language  design  phase, 3  for 
programming  support  environments  to  be  coupled 
with  the  language  to  ensure  the  improvements 
promised  by  the  language.  A  series  of  three 
documents  were  evolved  to  address  the  support 
issues:  SANDMAN,  early  1978;  PEQBLEMAN, 
mid -19 78;  and  STONEMAN,  early  1980.  The 
STONEMAN  document  became  the  basis  for  Ada 
programming  support  environments  (APSE's). 

Tha  Ada  community  was  focused  inward 
during  this  formative  time  for  the  Ada 
language.  Little  concern  was  given  for  the 
suitability  of  Ada  for  developing  trusted 
systems.  A  language  construct  existed  in  the 
pre-1980  version  of  the  language  that  could 
aid  program  verifiers  in  proving  program 


™Ada  is  a  registered  trademark  of  the 
U.S.  Government,  Ada  Joint  Program  Office. 
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Inc,  1983)  ,  pp.  14-16. 
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correctness/  The  construct  was  removed  in 
the  1980  version. 

Meanwhile,  back  at  the  ranch...  the 
computer  security  (COMPUSEC)  community  was 
continuing  to  grow.  In  1981,  the  DoD  Computer 
Security  Center  was  established,  and  COMPUSEC 
issues  continued  to  get  ever-increasing 
attention.  Tremendous  strides  have  been  made 
in  the  technical  areas  of  COMPUSEC,  and  this 
year  marks  the  tenth  anniversary  for  the 
National  Computer  Security  Conference.  Due  to 
its  formative  nature,  the  inward-focused 
syndrome  has  affected  the  COMPUSEC  community 
as  well. 

An  inward  focus  is  necessary  to  establish 
a  core  of  expertise  and  experts;  however,  a 
concerted  effort  must  be  made  to  focus 
outward,  each  community  to  the  other.  While 
there  has  been  a  significant  change  in  their 
focus  over  the  past  2  years,  a  relatively 
dichotomous  situation  still  exists  between 
these  two  communities.  We  must  establish  a 
strong  synergistic  relationship  between  the 
Ada  and  COMPUSEC  communities  in  order  to 
effectively  address  the  problem  of  using  Ada 
for  seen re/ trusted  systems. 

In  the  fall  of  1984,  the  Center  realized 
the  need  to  address  this  disjuncture  between 
the  Ada  and  COMPUSEC  communities.  The  Ada 
Technology  Insertion  Branch  was  established  in 
January  1985  within  the  Secure  Computer 
Networks  Division  of  the  Office  of  P.esearch 
and  Development  at  the  Center.  The  goal  of 
the  branch  was  to  foster  expertise  on  the 
implications  of  using  Ada  for  secure/trusted 
computer  networks.  To  achieve  this  goal,  the 
branch  outlined  its  objectives.  The  first 
priority  was  to  develop  the  necessary  internal 
knowledge  base  in  Ada  and  COMPUSEC,  A 
philosophy  of  "Learning  by  Doing"  was 
established  as  a  means  for  developing  this 
base.  To  focus  the  learning  effort,  the 
branch  initiated  the  Secure  Ada  protocols 
Project  (SAPP) . 

SAPP 

Given  the  previously  described  dichotomy, 
the  SAPP  team  decided  to  approach  the  problem 
from  a  real-world  perspective  by  implementing 
a  secure  protocol  suite  based  on  the  Defense 
Data  Network  (DDN)  specifications  of  transport 
control  protocol  (TCP) ,  internet  protocol 
(IP),  and  X.25.  Further,  we  decided  to  do  it 
in  Ada.  We  felt  that  implementation  of  this 
secure  protocol  suite  would  give  us  a 
significant  grasp  on  protocols  and  Ada  so  that 


^Peter  Wegner,  Programming  with  Ada ; 
An  Introduction  by  Means  of  Graduated 
Examples  (Englewood  Cliffs,  NJ : 
Prentice-Hall,  Inc.,  1980),  pp.  77-78. 
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we  could  begin  addressing  the  problem  of 
developing  the  same  suite  as  a  multilevel 
secure  (MLS)  suite.  Our  goal  was  to  use  Ada 
from  beginning  to  end,  including  the  use  of 
Ada  for  the  formal  specifications  and 
verification  activity.  We  understood  several 
things  at  that  time: 

a.  The  experts  said  Ada  was  not 
useful  for  the  development  of  secure/trusted 
software . 

b.  There  were  problems  with  the 
language  definition  that  must  be  addressed 
before  we  could  complete  our  task. 

c.  The  MIL-STD  documents  were 
inaccurate,  incomplete,  and  ambiguous  with 
respect  to  the  TCP  and  IP  protocols. 

d.  No  one  on  the  development  team 
knew  anything  about  protocols. 

e.  only  two  of  the  team  members  had 
ever  written  any  Ada. 

f.  At  the  beginning  of  the  project, 
we  did  not  have  a  validated  (approved)  Ada 
compiler . 

Eveii  with  those  problems  facing  us,  we 
believed  wo  could  accomplish  several  important 
objectives: 

a.  Train  our  people  in  Ada  and 
protocols. 

b.  Identify  constructs  of  the 
language  for  use  on  secure/trusted 
applications. 

c.  Identify  constructs  of  the 
language  requiring  modification  for  use  on 
trusted  software. 

d.  Develop  an  unambiguous, 
programmatical  statement  of  the  protocol 
standards  in  Ada. 

e.  Push  the  state  of  the  art  for 
developing  a  "beyond-Al"  MLS  system. 

f.  Develop  a  cadre  of  expertise  with 
respect  to  the  development  of  secure  protocols 
in  Ada. 

g.  Introduce  this  technology  to  the 
outside  communities  for  enhancement  and 
refinement. 

h.  Demonstrate  that  it  could  be 

done . 

We  defined  the  SAPP  in  three  phases: 

Phase  I  would  develop  a  working  understanding 
of  the  Ada  language  and  the  selected  protocol 
suite,  Phase  II  would  develop  a  demonstrable 
Ada  language  implementation  of  the  protocol 
suite,  and  Phase  III  would  develop  a  secure 
implementation  of  the  protocol  suite. 

Phase  I 

After  the  initial  staffing  and 
planning  of  the  branch,  work  proceeded  in  two 
areas  of  learning  -  the  Ada  language  and 


communications  protocols.  We  first  addressed 
the  lack  of  experience  in  protocols.  Each 
person  was  assigned  the  task  of  becoming 
intimately  familiar  with  one  of  the  major 
protocols  (such  as  TCP)  and  acquiring  a  basic 
overall  understanding  of  the  entire  protocol 
suite.  Most  of  the  training  for  protocols  was 
on  a  self-study  basis. 

Our  initial  programming  facilities 
were  Telesoft  and  Janus/Ada  subset  compilers 
for  the  IBM  personal  computers  (PC's).  With 
the  subset  compilers,  we  also  started  a 
self-study  of  the  Ada  language.  Using  the 
Janus/Ada,  we  prototyped  a  high-level  data 
link  control  protocol  between  two  IBM  PC/XT's. 
This  phase  was  completed  in  April  1986. 

Phase  xi 

This  phase  began  with  the  arrival  of 
the  RATIONAL  computer  system,  a  system  solely 
for  Ada  development,  in  February  1986.  After 
branch  personnel  received  formal  training  in 
Ada  as  well  as  training  on  the  RA3  )NAL,  we 
started  work  on  the  high-level  design  of  the 
protocol  suite.  Each  component  (TCP,  IP, 

X.25)  was  implemented  as  a  separate  process. 

An  Inter-Process  Communication  (IPC) 
specification,  independent  of  operating  system 
services,  was  developed  to  allow  communica¬ 
tions  between  components  of  the  suite. 

We  demonstrated  the  completed  suite 
(but  not  100%  full-featured)  approximately  1 
year  after  Phase  II  began.  As  the 
implementation  proceeded,  we  encountered 
problems  with  Ada  and  the  protocol 
specifications.  Both  TCP  and  IP  were 
developed  from  MIL-STD's  (1778  and  1777, 
respectively) .  These  specifications  were  in  a 
combination  of  state  diagrams  and  structure 
declarations;  the  declarations  were  in  a 
pseudo-Ada.  Some  of  these  were  very  difficult 
to  express  in  true  Ada.  Variant  record 
constructs  needed  to  be  used,  but  the  protocol 
MIL-STD's  were  erroneous  and  contradictory. 

In  addition,  the  description  of  variant 
records  in  the  Ada  Language  Reference  Manual 
(ALRM)  was  not  clear.  After  overcoming  these 
obstacles,  the  resulting  design  was  very  solid 
and  provided  a  better  (less  ambiguous) 
specification  than  the  original  MIL-STD's 
protocol  specifications. 

The  X.25  specifications  used  were  the 
CCITT  X.25  Recommendation  and  the  DDN  X.25 
Host  Interface  Specification.  The  specifica¬ 
tions  for  the  data  link  and  physical  levels  of 
X.25  are  in  prose.  Translating  these  specifi¬ 
cations  into  a  high-level  design  was  a  pains¬ 
taking  activity.  Even  though  the  specifica¬ 
tions  were  not  complete,  design  decisions  were 
easy  to  document,  and  the  resulting  Ada  speci¬ 
fication  was  very  readable.  The  high-level 
abstraction  capabilities  of  Ada  were  of  great 
help  in  this  design.  For  example,  the  ability 
to  state  user-defined  data  abstractions  made 
it  much  easier  to  specify  the  checksum 
algorithm  of  X.25.  We  defined  a  package  of 
polynomial  math  functions  and  specified  the 
checksum  algorithm  as  stated  in  polynomial 
form.  Some  minor  changes  were  required  for 
demonstration  performance,  but  no  change  in 
the  polynomial  abstraction  was  needed. 
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The  use  of  Ada  in  our  design  and 
implementation  appears  to  have  provided  a  very 
■-ortable,  programmatic  specification  of  the 
DDN  protocol  suite.  While  it  was  not 
optimized  for  real-time  performance,  our 
implementation  did  demonstrate  several  of  the 
objectives  outlined  earlier.  We  demonstrated 
that  programmatic  description  is  obtainable 
and  more  precise  than  the  standards.  In  the 
area  of  Ada,  we  learned  the  language  by  using 
it.  We  used  all  of  the  constructs  in  the 
language,  including  generic  packages  with 
internal  tasks  and  dynamically  allocated  tasks 
(via  task  types) . 

At  the  writing  of  this  paper,  we  were 
in  the  process  of  porting  our  implementation 
from  the  RATIONAL  to  VAX/VMS  with  DEC  Ada. 
Phase  II  of  the  project  is  coming  to  a  close 
and  we  are  proceeding  into  Phase  III. 

Phase  III 

This  phase  of  the  SAPP  involves  the 
prototype  development  of  an  MLS  protocol 
suite.  Work  begins  with  the  development  of 
the  Security  Policy,  followed  by  the  Formal 
Model,  Formal  Top  Level  Specification  (FTLS) , 
and  the  implementation  in  Ada.  The  approach 
to  this  phase  is  to  take  a  global  view  of  the 
development  of  a  trusted  protocol  suite. 

While  it  is  important  that  we  pursue  the  use 
of  Ada  throughout  the  entire  development,  we 
are  not  going  to  pursue  basic  research  in  the 
area  of  developing  proof  rules  and  verifica¬ 
tion  systems.  However,  we  will  be  working 
closely  with  those  who  are  doing  tiiis  basic 
research,  both  within  and  outside  the  Center. 

There  are  initial  issues  about  what 
is  the  correct  policy  and  formal  model  for  a 
network,  how  does  the  pop  Trusted  Computer 
Security  Evaluation  Criteria  apply,  and  how 
do  you  measure  levels  of  trust  outside  of 
verification  technology.  We  will  consider  the 
use  of  requirements  tracing  tools  and  software 
engineering  principles  to  provide  higher 
levels  of  trust.  We  plan  to  concentrate  op 
some  of  these  issues  as  work  progresses. 

While  proceeding  through  this  phase, 
Ada  and  Ada-based  technology  will  he  used 
wherever  possible.  We  are  committed  to  using 
an  Ada — based  specification  language  for  the 
FTLS;  Anna'’  looks  like  an  initial  candidate  to 
use.  No  verification  environment  currently 
exists  for  Ada-based  languages,  and  oui 
initial  effort  will  proceed  by  using  hand 
verification  of  our  specifications.  The 
ultimate  benefits  of  not  having  to  translate 
the  FTLS  to  a  different  implementation 
language  will  offset  this  initial  problem. 

The  ultimate  hope  is  that  this 
project  will  produce  a  comp!ete,  programmatic, 
MLS  description  of  the  protocol  suite  which 
has  been  verified  down  through  90%  or  more  of 
the  source  code. 


Anna  is  an  MHo  _ated  language 
developed  at  Stanford  universi  .y  by  Dr. 
Luckham,  et  al. 


IWrERACTIOBS 

As  the  work  progresses,  the  branch  will 
continue  to  interact  with  the  government, 
academic,  and  industrial  communities  to  foster 
interielations  with  the  Ada  and  COMPIJSEC 
communities.  We  have  worked  with  two  groups 
that  are  especially  worthy  of  note:  the 
Kernel  Ada  Programming  Support  Environment 
(KAPSE)  Interface  Team  (KIT)  and  the  Ada 
Run-Time  Environments  Working  Group  ( ARTEWG) 
of  the  Special  Interest  Group  on  Ada  (SIGAda) . 

KIT 

The  KIT  was  established  by  a 
memorandum  of  agreement  between  the  Army, 

Navy,  and  Air  Force.  As  was  mentioned,  the 
DoD  realized  the  need  for  programming  support 
environments.  It  was  also  realized  that  a  set 
of  interfaces  needed  to  be  defined  for  the 
APSE'S  to  the  underlying  operating  systems 
that  would  give  much  greater  portability  to 
tools  tha'.  were  written  and  allow  data  to 
interoperate  among  the  APSE's.  The  set  of 
interfaces  that  were  defined  by  the  KIT  is 
known  as  the  Common  APSE  Interface  Set  (CAIS) . 
Through  our  involvement  with  the  KIT,  MLS 
requirements  were  inserted  into  the  CAIS  in 
1985.  Currently,  CATS  is  the  only  DoD 
Standard  that  references  the  need  for  both 
Ada  and  a  B3-level  security. 

ARTEWG 

The  ARTEWG  is  a  part  of  the  Associ¬ 
ation  of  Computing  Machinal  y  ‘  s  (ACri's)  SIGAuo. 
Their  objective  is  to  address  the  issues  of 
t.he  runtime  environment  for  Ada.  The  Ada 
language  provides  a  sharp  delineation  between 
the  compiler,  the  runtime  environment,  and  the 
operating  system.  Many  of  the  obstacles  that 
need  tc  be  overcome  in  the  verification  arena 
are  directly  attributable  to  implementation 
dependencies  in  the  runtime  environment.  The 
ARTEWC  has  published  three  papers  that  give 
tremendous  insight  into  the  Ada  runtime. 

"A  Canonical  Model  and  Taxonomy  of 
Ada  Runtime  Environments"  provides  an 
historical  perspective  on  the  evolution  of 
executives  and  operating  systems  to  provide 
services  to  the  application  programs.  The 
paper  further  suggests  that  the  Ada 
compilation  system  can  generate  its  own 
application  specific,  runtime  system  to  run  on 
a  bare  machine. 

"Catalogue  of  Ada  Runtime 
Implementation  Dependencies"  is  a  first  pass 
at  identifying  all  of  the  allowed  options  for 
implementing  the  runtime  support  for  Ada 
compilers.  The  catalogue  is  going  through 
peer  reviews  in  the  ARTEWG,  the  Performance 
Issues  Working  Group  (PIWG) ,  and  many  ochers. 
This  paper  is  intended  to  be  an  exhaustive, 
authoritative  list  of  all  the  runtime 
implementation  dependencies. 

"A  Catalog  of  Interface  Features  and 
Options  for  the  Ada  Run  Time  Environment" 
(CIFC)  is  similar  in  intent  to  the  CAIS. 

Release  1.0  is  a  baseline  document  for  the 
CIFO.  This  paper  is  geared  towards  providing 
a  standard  specification  for  a  set  of  common 
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interfaces  between  the  user  and  the  runtime 
environment. 

These  three  papers  ate  very  good  in 
relation  to  the  Ada  runtime  environments,  but 
all  three  are  devoid  of  CGMPUSEC.  The  ARTEWG 
is  concerned  about  COMrUSEC  and  is  seeking 
input  on  the  issues  of  security  in  relation  to 
the  runtime  environment. 

COHCLOSIOHS 

Concerns  of  the  impact  of  Ada  technology 
on  C0MPU3EC,  and  vice  versa,  are  moving  to  the 
forefront,  with  projects  like  the  Strategic 
Defense  Initiative  (which  has  already  decided 
vo  use  at  least  an  Ada-based  Process 
Description  Language  [ FDL] )  and  the  NASA  Space 
Station  (which  has  decided  to  use  Ada  as  the 
implementation  language) . 

We  challenge  both  the  COMPL'SEC  and  Ada 
communities  to  develop  the  synergistic 
relationship  that  is  necessary  to  understand 
and  resolve  the  problems  of  using  Ada  in  and 
for  trusted  systems. 
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A  Panel  Discussion 
*  0,1 

Ada  and  COMPUSEC 


This  panel  presentation  provides  an  open 
forum  to  begin  an  earnest  oialogue  on  Ada  and 
computer  security  (COMPUSEC)  and  their  unique 
problems  and  concerns  in  relation  to  each 
other.  From  1975  to  1983,  two  areas  of 
concern  were  being  stressed  within  the  Federal 
Government  (the  Department  of  Defense  in 
particular)  and  industry:  escalating  software 
costs  and  computer  security.  This  concern 
culminated  in  the  establishment  of  two 
standards.  The  Ada  programming  language 
became  an  ANSI/Military  standard  on  17 
February  1983,  and  the  Department  of  Defense 
Trusted  Computer  System  F.valua tion  Criteria 
was  published  on  35  August  1983  as  a  DoD 
Computer  Security  Center  guideline.  In 
December  1986,  the  Criteria  was  accepted  as  a 
DoD  standard  (5200.28-STD) .  Both  standards, 
as  well  as  their  ensuing  policies,  were 
developed  separately  from  each  other. 

With  projects  like  the  Strategic  Defense 
Initiative  (which  lias  already  decided  to  use 
at  least  an  Ada-based  Process  Description 
Language  [ PDL] )  and  the  NASA  Space  Station 
(which  has  decided  to  use  Ada  as  the 
implementation  language),  concerns  of  the 
impact  of  Ada  technology  on  COMPUSEC,  and  vice 
versa,  are  moving  to  the  forefront. 

The  panel  members  ate: 

Mr.  Clarence  Ferguson,  Panel  Moderator, 
Chief,  Ada  Technology  Insertion  Branch,  Office 
of  Research  and  Development,  National  Computer 
Security  Center  (NCSC) 

Ms.  Virginia  Castor,  Director  of  the  Ada 
Joint  Program  Office  (AJPO) 

Dr,  Charles  McKay,  Director  of  the  NASA 
Software  Engineering  Research  Center  (at  the 
University  of  Houston,  Clear  Lake) 

Mr.  Robert  Morris,  Chief  Scientist,  NCSC 


* 

Ada  is  a  registered  trademark  of  the 
U.S.  Government,  Ada  Joint  Program  Office. 
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TM 

THE  USE  OF  Ada  IN  SECURE  AND  RELIABLE  SOFTWARE 


Mark  E  Woodcock 

Office  of  Research  and  Development 
National  Computer  Security  Center 


"Am  I  so  crazy  to  feel  it's  here  prearranged? 

The  music  must  changel!" 

-Fete  Townshend,  "The  Music  Must  Change" 
Who  Are  You,  Eel  Pie  Publishing,  1977 


ABSTRACT 

The  Department  of  Defense  (Don)  has  an 
obvious  need  for  secure  and  reliable  computing 
systems.  Its  language  of  choice,  Ada,  should 
be  well  suited  to  the  development  of  these 
systems.  Although  it  currently  has  some 
features  which  make  it  better  suited  to  these 
tasks  than  most  programming  languages,  Ada 
still  requires  a  number  of  changes  to  properly 
fulfill  its  mission.  The  imprecise  definition 
in  Ada's  Language  Reference  Manual  renders  Ada 
programs  inconsistent  from  compiler  to  com¬ 
piler  and  cannot  be  guaranteed  to  be  reliable 
nor  formally  verified  to  meet  the  DoD  computer 
security  criteria.  The  Ada  community  must 
make  a  commitment  to  see  that  the  research  is 
completed  to  enable  Ada  to  fulfill  both  secu¬ 
rity  requirements  and  its  own  requirements. 

THE  PURPOSE  OF  ADA 

In  the  mid-70's,  the  U.S.  Department  of 
Defense  (uou)  noticed  its  increasing  depen¬ 
dence  on  mission-critical  software  and  that 
the  cost  of  this  software  was  growing  rapidly. 
It  has  been  estimated  that  as  much  as  $30  bil¬ 
lion  a  year  would  be  needed  for  software  pro¬ 
curement.  [1]  Because  one  of  the  key  contribu¬ 
tors  to  this  cost  was  the  need  to  retrain  pro¬ 
grammers  and  rewrite  programs  when  different 
languages  were  used,  a  decision  was  made  to 
create  a  single  programming  language  which 
could  be  used  in  all  embedded  systems  (this 
includes  all  mission-critical  and  weapon  sys¬ 
tems)  .  [4] 

The  DoD  also  noted  that  programs  which 
were  almost  identical  in  functionality  were 
quite  often  implemented  completely  differently 
because  of  the  choice  of  run-time  environment 
(compiler,  operating  system,  etc.).  What  was 
needed  was  not  just  one  programming  language, 
but  one  that  was  consistent  from  implementa¬ 
tion  to  implementation;  an  environment  which 
would  enable  programs  and  programmers  to  move 
freely  from  one  machine  to  the  next. 

The  result  was  Ada.  "Ada  was  designed 
with  three  overriding  concerns:  program  relia¬ 
bility  and  maintenance,  programming  as  a  human 
activity,  and  efficiency"  (section  1-3,  [3]). 
It  was  intended  to  be  usable  in  any  mission- 
critical  system,  to  exploit  the  advances  being 
made  ir.  software  engineering,  and  to  be  easily 
portable  (within  system  size  and  speed  limita¬ 
tions)  . 
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PROBLEMS 

Clearly  these  were  ambitious  criteria; 
they  remain  beyond  the  capabilities  of  any 
existing  language.  While  making  great  strides 
in  achieving  several  of  these  goals  (particu¬ 
larly  in  exploiting  the  newest  developments  in 
software  engineering  and  usefulness  for  real¬ 
time  systems) ,  Ada  tried  to  be  too  much  for 
too  many  people.  Although  the  language  does 
not  have  to  be  radically  altered,  some  signi¬ 
ficant  changes  are  needed  in  order  to  com¬ 
pletely  fulfill  its  requirements. 

1 .  Sec nr i t  y 

In  approximately  the  same  time- 
period  that  Ada  was  being  developed,  the  con¬ 
cepts  that  determine  the  security  of  a  comput¬ 
ing  system  were  being  defined.  The  features 
of  the  language  are  not  directly  critical  to 
the  security  of  the  system,  but  they  do  play  a 
key  role  in  the  reliability  (whether  the  sys¬ 
tem  operates  in  a  manner  consistent  with  its 
specif [cations) .  Since  secure  systems  are 
supposed  to  be  reliable  (and  the  language 
effects  the  reliability),  the  features 
indirectly  determine  a  system's  security. 

According  to  the  DoD  Trusted  Com¬ 
puter  System  Evaluation  Criteria  (TCSEC)  |4J, 
the  design  of  a  system  to  Tac  classified  at  the 
A1  level  must  be  verified  using  one  of  the 
tools  endorsed  by  the  National  Computer  Secu¬ 
rity  Center  (NCSC)  (e.g.,  Gypsy  Verification 
Environment  [GVEJ  and  Formal  Development 
Methodology  [ FDMJ ) .  Formal  verification  of  a 
design  (or  a  program)  requires  that  the 
language  used  to  describe  it  must  be  mathemat¬ 
ically  well-defined.  (Ada,  for  reasons  that 
will  be  described  below,  is  not.)  These  tools 
require  that  a  particular  design  language, 
created  specifically  for  that  system  (Gypsy 
for  GVF.  |5]  and  Ina  Jo  for  FDM  [6)),  be  used 
in  order  to  reach  the  highest  security  clas¬ 
sification. 

The  DoD  now  requires  the  use  of 
an  Ada-based  Program  Design  Language|2J,  how¬ 
ever,  in  designing  its  software  systems.  This 
criterion  is  not  completely  consistent  with 
the  TCSEC  (particularly  given  DoD's  desire  no' 
to  allow  waivers).  Because  the  A1  classifica¬ 
tion  does  not  address  the  issue  of  the  imple¬ 
mentation  lar.guaqe,  a  system  may  be  designed 
using  one  of  the  endorsed  tools  and  then 
implemented  in  Ada.  This  is  possible  because 
no  formal  proof  of  the  source  code  is  neces¬ 
sary  for  an  A1  evaluation.  "Manual  or  other 
mapping  of  the  FTLS  (formal  top-level  specifi¬ 
cation)  to  the  TCP  (trusted  computing  base) 
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source  code  shall  be  performed  to  provide  evi¬ 
dence  of  correct  implementat ion (page  48, 

[4])  Therefore,  any  implementation  language 
may  be  used  for  an  A1  system. 

This  will  not  be  true  of  the 
"beyond  Al"  criteria  when  they  become  better 
defined.  One  of  the  requirements  being  con¬ 
sidered  for  the  A 2  criteria  is:  "The  TCD  must 
be  verified  down  to  the  source  code  level, 
using  formal  verification  methods ..."( page  51, 
14])  Unfortunately,  Ada  coae  cannot  be  veri¬ 
fied  because  the  language  is  not  well-defined. 
While  we  will  soon  reach  a  point  where  Ada 
will  be  required  for  use  in  these  secure  sys¬ 
tems,  Ada  cannot  meet  the  above  requirement 
and  could  never  be  used  in  any  phase  of  the 
development  of  a  system  intended  to  be 
evaluated  at  the  A2  level. 

2 .  Definition 

The  present  version  of  Ada  is 
defined  by  the  MIL-STD  1815A.I3J  The  seman¬ 
tics  of  the  language  are  "described  by  means 
of  narrative  rules"  that  are  composed  of 
t.  clinical  and  other  terms.  The  t.chnical 
terms'  "precise  definition  is  given  in  the 
text"  and  the  other  terms  "are  in  the  Lnglish 
Language  and  bear  their  natural  meaning,  as 
defined  in  Webster's  Third  New  International 
Dictionary  of  the  Fngiish  Larguaqe . " ( sec t ion 
1-5,  13]).  This  means  that  Ada  is  defined  by 

the  use  of  a  natural  language  (Eng’-sh) — not  a 
well-defined,  mathematical  language. 

Natural  languages  have  proven  to 
be  too  complex  t.o  be  used  as  the  basis  of  a 
mathematical  proof  (that  is,  it  cannot  be  done 
and  never  will  be] .  The  existence  of  the 
validation  suite  does  not  solve  the  problem. 

It  cannot  even  guarantee  that  a  compiler  fully 
meets  the  requirements  of  the  Language  Refer¬ 
ence  Manual  ( LPM ) 1 3 }  (not  that  any  va, idation 
suite  could),  let  alone  be  useful  as  a 
mathematical  definition.  r.;  ace  verification 
is  dependent  on  the  ability  to  perform 
mathematics'  uroofs,  Ada  cannot  be  verified  as 
it  present'  'ists, 

L'</.n  he  effort  was  made  to  translate 

the  d  ■>  of  Ada  into  some  precise 

math.  •  i  rrion  (such  as  the  denota- 

tj.oi  ■  recently  completed  by  the 

Dans  -  Fenter  [ DDC ] ) ,  however,  two 

signi  .  ,  of  problems  would  remain. 

The  first.  -  the  DoD,  in  its  quest  to 

leave  no  construct  out  of  the  language, 
included  certain  language  features  whose 
correctness  may  be  impossible  to  formally 
prove  (e.g.,  dynamic  tasking,  generics).  The 
second  problem  is  that  allowing  compilers  to 
implement  a  particular  feature  in  many  dif¬ 
ferent  ways  (sometimes  even  to  the  point  that 
one  compiler  may  use  more  than  one  approach 
deperding  on  the  situation —  opt ima t i zat ion 
ve.sus  normal  operation]  makes  it  impossible 
to  know  rxactb'  what  that  feature  really 
means . 


Consider  the  following  piece  of 

Ada  code: 

package  example  is 

function  f  (x:in  out  integer) 
returns  integer; 
function  g  (x:in  out  integer) 
returns  integer; 

end  example; 

package  body  example  is 

y:  integer ; 

function  f  (x:  in  integer) 

return  '  *-eger  is 

beg  i  n 
y .  =  x*x  +  y ; 
return  y; 
end ; 

function  g  (x:  in  integer) 

return  integer  is 

beg  in 
y :=2*x+y; 
return  y; 
end : 

beg  i  n 
y:=l; 

end  example; 
y :  =  f  (x)  +  g  (x)  ; 


Tliis  is  obviously  a  very  simple 
example  (of  the  order  of  evaluation  problem), 
and  any  moderate)  y-ir, tel  1  igent.  programmer 
would  not  generate  such  dangerous  code.  While 
any  third-year  computer  science  student  would 
notice  this,  no  Ada  compiler  is  required  to 
discover  this  problem.  Since  the  two  func¬ 
tions  referenced  xe  the  assignment  statement 
have  side  effects,  the  value  ol  the  assignment 
statement  will  vary  dependent  on  cho  order  of 
evii’jation  (left-to-riybt  or  cight-to-lef t)  . 

There  are  also  much  more  compli¬ 
cated  problems.  Whr n  passed  as  a  parameter, 
an  atomic  variable's  (integer)  value  is  passed 
(copy  in).  When  3  structure  (such  as  on 
arrayj  is  passed,  however,  it  may  be  passed  by 
reference  (its  address  is  passed).  parameters 
that  are  passed  by  value  are  tlways  protected, 
K-it  parameters  passed  by  reference  may  be 
altered  by  the:  operation  of  some  other  task 
(without  the  knowledge  of  the  subprogram  in 
question;  which  arso  has  a  pointer  to  the  same 
variable. 

This  situation  is  particularly 
bad  because  the  operation  of  the  program  may 
change  from  one  execution  to  tne  next,  not 
just  between  machines  or  compilers.  Even  pro- 
tecrior  schemes  may  fail,  like  checking  the 
value  of  the  variable  and  then  performing  some 
dangerous  operation  on  it  (this  is  known  as 
the  "time  of  check — time  of  use"  proDlem)  . 

Fo,  example,  a  task  might  check  it  a  variable 
is  zero  before  using  it  as  a  divisor,  but  the 
check  is  no  guarantee  of  correcLiiess  if 
another  task  may  alter  that  location’s  value 
betore  it  is  used  This  means  that  a  program 
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could  run  perfectly  when  tested  but  still  fail 
(or  give  incorrect  results)  during  actual 
operation. 

This  scenario  also  raises  the 
possibility  of  a  significant  security  flaw. 

One  user  (even  at  ttie  unclassified  level) 
could  write  Ada  code  using  tasking,  shared 
variables,  and  call  by  reference  which  would 
enable  him  to  bypass  even  the  most  secure 
existing  computing  systems  and  read  any  data 
(at  any  level)  in  the  system.  While  this  is 
not  an  Ada-specific  problem,  Ada  does  make  it 
quite  easy  to  accomplish. 

Chapter  13,  Representation 
Clauses  and  Implementation-Dependent  Features/ 
of  the  LRM  [3]  is  a  list  of  optional  features 
which  may  be  implemented  by  the  compiler. 

While  this  list  at  least  standardizes  the 
variations  between  compiler  versions/  it  does 
not  change  the  fact  that  any  program  which 
uses  one  of  these  features  is  limited  to  a 
compiler  which  implements  that  feature. 

One  of  the  biggest  problems  with 
Ada,  though,  is  the  Run-Time  Support  Package. 
The  run-time  support  needs  of  most  programming 
languages  is  quite  small.  C's  support  package 
of  a  few  instructions  is  dwarfed  by  the 
thousands  of  lines  of  code  that  may  be 
required  to  run  an  Ada  program.  Not  only  does 
all  this  extra  code  (which  is  not  validated) 
open  vast  new  possibilities  for  errors,  the 
system-specific  features  of  each  compiler's 
support  package  make  portability  even  more 
difficult. 

In  the  short  run,  it  will  be 
necessary  to  select  one  valid  implementation 
for  the  language's  features,  validate  the  sup¬ 
port  package,  and  avoid  using  the  more  complex 
constructs  to  create  a  "verifiable"  subset. 
(Note  well  that  this  does  not  necessarily 
require  that  a  subset  compiler  be  used,  only 
that  secure  programs  use  only  the  appropriate 
subset.)  Larger  and  larger  parts  of  the 
language  will  be  usable  as  verification  tech¬ 
nology  becomes  more  robust,  but  the  require¬ 
ment  for  a  concise  mathematical  definition 
will  imain.  While  this  will  not  please  the 
hardline  Ada  supporters,  it  could  enable  Ada 
to  be  used  for  tnc  design  of  secure  systems. 

RESEARCH  EFFORTS 

The  NCSC,  through  the  Consolidated  Com¬ 
puter  Security  Program,  is  pursuing  a  two¬ 
pronged  strategy  to  improve  the  state  of  Ada 
verification  technology.  The  first  is  a 
short-term  effort  to  demonstrate  the  feasibil¬ 
ity  of  such  a  verificati  i  system  and  to  give 
the  community  a  starting  point  for  discussion 
and  future  work.  This  effort  is  being  con¬ 
tracted  through  the  Rome  Air  Development 
Center  to  Odyssey  Research  Associates. 

The  second  part  is  a  long-term  effort  to 
produce  a  production  quality  system  and  is 
being  contracted  through  the  Defense  Communi¬ 
cations  Agency.  The  first  phase  is  a  back¬ 
ground  study  and  technology  evaluation  being 
done  by  IIT  Research  Institute.  After  comple¬ 
tion  of  this  study,  a  request  for  proposal 
will  be  issued  for  the  design  of  a  complete 


Ada  Verification  Environment  (AVE) ,  and  a  con¬ 
tract  award  is  anticipated  late  this  year. 

A  number  of  other  efforts  are  underway  to 
better  define  Ada,  Dr.  David  Luckham  at  Stan¬ 
ford  University  continues  to  work  on  the  Ada 
specification  language,  Anna,  which  will  pro¬ 
vide  an  operational  definition  of  Ada.  (Anna 
is  also  being  used  in  several  other  projects.) 
DDC  has  just  completed  a  denot.ational  semantic 
definition  of  the  language  for  the  European 
Economic  Community.  There  are  also  several 
people  working  on  axiomatic  proof  rules  for 
Ada , 

WHY  Ada  HAS  TO  CHANGE 

The  one  thing  which  has  to  be  made  really 
clear  is  that  the  changes  suggested  are  not 
just  for  some  rarely-applied  or  as  yet  non¬ 
existent  security  criteria.  While  the  primary 
motivation  for  this  paper  is  convincing  the 
Ada  community  that  it  should  prepare  to  meet 
the  TCSEC  security  requirements,  there  are  a 
lot  of  other  good  reasons  Cor  these  changer  to 
be  made. 

3oth  the  Strategic  Defense  Initiative  and 
the  NASA  Space  Station  project  intend  to  use 
Ada  as  a  design  and  implementation  language. 
Regardless  of  how  secure  these  systems  turn 
out  to  be,  they  must  be  reliable.  When 
kinetic-kill  weapons  and  high-powered  lasers 
start  firing,  you  want  t;  bo  very  sure  that 
they  are  working  correctly.  The  only  way  to 
achieve  the  desired  level  of  reliability  is 
through  formal  v  e  i ifi cation. 

Moreover,  it  would  be  more  cost-effective 
over  the  life-cycle  of  the  product  if  Ada  sys¬ 
tems  are  formally  verified.  Tne  maintenance 
cost  on  a  system  that  works  correctly  will  be 
virtually  non-existent.  Shi uld  enhancements 
ever  be  needed,  the  design  of  the  system  will 
be  so  clearly  stated  and  its  interfaces  so 
precisely  defined  that  the  changes  could  be 
made  easily  and  cheaply. 

It  is  clear  that  Ada  has  still  not  met 
its  original  criteria.  There  are  programs 
which  have  been  written  that  will  compile  on 
one  validated  Ada  compiler  but  not  on  others. 
It  this  is  possible,  more  subtle  errors  than  a 
failure  to  compile  are  possible.  This  means 
there  is  no  guarantee  that  an  Ada  program  will 
be  portable  in  a  reliable  way  and  the  existing 
understanding  of  Ada  is  not  sufficiently 
better  than  that  of  any  other  implementation 
language.  This  suggests  that  even  on  the  sys¬ 
tem  for  which  it  was  created,  an  prootani 

will  be  no  more  reliable  than  -am  writ¬ 

ten  in  another  high-level  langi 

CONCLUSION:  WHAT  HAS  TO  BE  DONE 

The  notion  presently  exists  that  Ada  is 
truly  the  single,  clearly-defined  language 
that  the  DoD  originally  requested  Unfor¬ 
tunately,  this  is  not  true.  Instead  of  having 
different  version  names  (FORTRAN  IV,  77, 
vanilla) ,  we  now  have  Ada  differing  by  the 
compiler  for  which  it  was  written.  Even  more 
significant  is  that  Ada  is  not  sufficiently 
well-defined  to  make  it  useable  in  a  secure  c-r 
reliable  way. 
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Ada  is  not  much  worse  than  any  other 
high-order  language  -  it  just  includes  all 
their  flaws.  The  difference  is  Ada  promised 
more,  is  expected  to  be  used  more  widely  (par¬ 
ticularly  for  security),  and  has  an  organized 
system  for  change  (the  Language  Maintenance 
Board)  . 

What  is  needed  is  an  acceptance  by  the 
Ada  community  that  Ada  will  have  to  become 
formally  defined  and  internally  consistent  if 
it  is  to  remain  the  language  of  choice.  Ada 
has  made  significant  strides  in  syntax  stan¬ 
dardization  and  the  inclusion  of  software 
engineering  techniques  in  the  language  struc¬ 
ture,  but  it  still  needs  significant  improve¬ 
ments.  When  the  Ada  community  becomes  con¬ 
vinced  of  this  fact,  the  existing  work  to 
define  Ada  can  be  accelerated  and  goals  of  the 
future,  as  well  as  the  language's  original 
requirements,  can  be  met. 
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Abstract 

A  group  at  Odyssey  Research  Associates  is  building 
an  environment  for  the  formal  verification  of  Ada  pro 
grains.  These  p/ograms  will  be  verified  against  specifi¬ 
cations  written  in  PolyAnna,  a  high-order  specification 
language  based  on  Anna.  PolyAnna  and  Anna  use  asser¬ 
tions!  reasoning,  and  v/e  describe  a  logical  foundation  for 
the  assertion  language.  We  present  a  thumbnail  sketch 
of  Anna,  and  a  list  of  ways  we  have  modified  Anna.  We 
present  an  overview  of  how  PolyAnna  differs  from  other 
verification  DVoteuis,  and  We  leview  sonic-  fealuies  of  Ada 
that  must  be  restricted  to  make  verification  of  Aria  pro¬ 
grams  possible  We  conclude  with  a  prospective  account 
of  the  higher-order  parts  of  PolyAnna,  and  an  explain 
tion  of  why  these  aje  suited  to  Ada  verification. 

Introduction 

One  good  reason  to  build  tools  for  the  formal  verification  of 
Ada  programs  is  the  expectation  that  they,  and  the  verified 
programs,  might  be  used  Ada  compilers,  it  is  assumed,  will  be 
widely  available  and  Ada  programmers  as  numerous  as  fleas.  If 
formally  verified  software  were  in  general  use,  one  could  learn 
whether  the  higher  production  costs  of  such  software  arc  justi¬ 
fied  by  higher  reliability  and  by  savings  in  testing  and  mainte¬ 
nance.  A  group  at  Odyssey  Res<  nnh  Associates  is  designing  u 
specification  language  for  Ada  and  a  verification  environment 
for  proving  the  correctness  of  programs,  specified  in  that  lan 
guage.  We  plan  to  have  a  running  system  for  a  useful  fragment 
of  the  specification  language  by  the  fall  of  1988. 

The  specification  language  can  be  separated  into  two  parts: 

•  A  ground-floor  language,  based  on  Alma,  supporting  pio- 
gramming  in  the  small  (at  the  level  of  subprograms  and 
packages); 

«  A  higher -order  polymorphic  language  (naturally  enough 
called  PolyAnna)  supporting  programming  in  the  large. 

The  ground  floor  will  be  implementable  by  application  and 
adaptation  of  established  theory.  Its  expressive  power  is  com 
prjablc  to  that  of  Gypsy  or  EHDM  [Gypsy  8C.EI1DM  8G]  Its 


underlying  logic  is  a  logic  of  partial  functions  that  correctly  han¬ 
dles  undefined  expressions,  and  it  is  in  this  respect  an  advance 
on  those  systems.  We  have  not  yet  studied  proof  checking  and 
term  rewriting  in  this  logic,  but  we  expect  standard  techniques 
to  apply. 

Pull  PolyAnna  will  require  new  research  in  higher-order  lan¬ 
guages  and  polymorphism.  There  are  active  and  fashionable 
topics  of  research.  At  the  end  of  this  paper  we  sketch  some  well 
known  reasons  why  a  polymorphic  language  is  especially  suited 
for  specifying  Ada  programs. 

Our  primary  goal  for  our  software  is  that  it  support  incremental 
verification,  rather  than  batch  generation  of  verification  condi 
tions.  We  want  to  provide  automated  assistance  for  the  pro¬ 
gramming  style  prominently  associated  with  Dijkstra,  Hoa-r, 
and  Gries,  that  of  developing  a  program  and  its  proof  hand  in 
hand.  (See,  e.g.,  [Gries  83]  or  [Dijl  86].) 

The  ground  floor 

Assertional  reasoning 

Our  strategy  for  verification  is  assertional  reasoning  about  pro 
grams.  An  embedded  assertion  is,  in  effect,  a  comment  -it  stip¬ 
ulates  that  some  condition  (the  assertion)  is  satisfied  by  the 
program  state  every  tune  control  reaches  some  point  in  the  pro 
gram  text  (the  point  at  which  it  is  “embedded”).  The  language 
in  which  these  conditions  are  expressed  is  cali«'d  the  assertion 
language. 

Assertional  reasoning  about  programs,  formally  introduced  in 
the  famous  papers  of  Floyd  (Floyd  07]  and  Hoare  [Hoar-’  G9],  is 
a  set  of  techniques  that  reduces  the  proof  of  general  properties 
of  programs  to  the  proof  of  finitely  many  logical  formulas  in 
the  assertion  language.  A  epical  program  property  provable 
in  this  way  is:  if  subprogram  P  is  called  in  a  state  satisfying 
entry  condition  y\  then  it  will  terminate  in  a  state  satisfying 
exit  condition  i/’- 

By  contrast,  transformational  methods  begin  with  a  specifica¬ 
tion  of  the  desired  behavior  and  attempt  to  rewrite  t,  by  ap 
plying  a  series  of  meaning  preserving  transformations,  a-s  an  ox 
ecutable  program.  For  example,  one  might  specify  a  program 
recursively  and  apply  an  automatic  transformation  to  rewrite 
the  recursion  as  an  iteration.  The  European  Economic  Column 
-ility  is  sponsoring  a  consortium  of  several  European  universities 
in  a  very  ambitious  project,  PHOSPKCTKA  [KB  86],  to  build  a 
transformational  programming  environment  for  Ada. 
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For  our  ground  floor  wo  use  the  assertional  strategy  because: 

•  It  is  well  understood  and  therefore  holds  out  a  reasonable 
probability  of  success; 

•  There  is  an  established  pedagogy  of  writing  programs  as- 
sertionaliy,  which  we  hope  to  support; 

»  Assertional  reasoning  is  unlikely  to  be  entirely  avoidable 
a  transformational  system  must  provide  a  facility  for  es¬ 
tablishing  new  transformation  rules,  and  the  best  under 
stood  way  of  doing  that  is  assertional  reasoning. 

Writing  assertions  about  Ada:  Anna 

Anna,  described  by  its  designers  as  “a  cautions  extension  of 
Ada,'1  is  a  method  of  inserting  formal  comments  into  Ada  pro 
grams.  Most  of  these  comments  can  be  translated  into  em¬ 
bedded  assertions.  The  commented  Ada  program  is  an  Anna 
program,  and  it  contains  the  full  sense  of  the  original  Ada  pro¬ 
gram,  which  is  called  the  underlying  Ada  text.  An  Anna  pro¬ 
gram  can  be  transformed  into  an  Ada  program  that  runs  the 
underlying  text  and  checks  many  of  the  embedded  assertions. 
Accordingly,  Anna  can  be  thought  of  as  an  extension  of  Ada 
with  extra  cheeking  constructs,  and  which  compiles  into  Ada. 

Anna  object  and  type  annotation .1  are  associated  with  scopes. 
These  can  bo  interpreted  as  macro  instructions  embedding  as¬ 
sertions  at  certain  points  within  then  scopes  (not  merely  at 
entry  and  exit  points).  Anna  also  allows  axioms,  which  spec 
ify  packages  as  abstract  data  type’s  or  as  state  machines,  and 
virtual  text,  which  can  embody  specification  concepts  or  instru¬ 
mentation. 

Here  is  a  typical  Anna  type  annotation: 

type  EVEN  is  INTEGER: 

-■|  where  x:  EVEN  ->  x  mod  2=0; 

The  formal  comment  (preceded  by  -*  I )  says  that  every  variable 
of  type  EVEN  must  contain  an  even  value  (whenever  it  contains  a 
defined  value  at  all).  It  applies  to  every  observable  state  over  the 
whole  scope  of  the  declaration  of  type  EVEN.  If  the  annotation  is 
transformed  into  checking  code,  the  code  will  raise  the  exception 
ANNA.EXCEPTION  whenever  a  variable  of  type  EVEN  is  assigned 
an  odd  value. 

Hire  are  some  typical  axioms,  describing  the  semantics  of  a 
stack  type: 

—  I  axiom 

-'I  for  all  St:  STACK;  X:  ELEM  => 

"*l  pop(push(8t ,x))“St , 

--I  top(push(st ,x) ) =x ; 

We  assume  that  type  STACK  is  a  private  type  of  a  package,  and 
that  pop,  push,  and  top  are  visible  subprograms  of  that  package. 
The  annotation  says:  whenever  all  calls  referred  to  terminate 
normally,  the  equations  hold 

Filially,  as  an  example  of  virtual  text,  we  declare  a  virtual  funr 
•  ion  that  tells  us  whether  an  array  of  type  T  is  sorted  Tin*  ---. 
sign  marks  the  virtual  text  text  which,  if  the  comment  sign 
were  removed,  would  be  legal  Ada: 


— :  function  t  jrted(a:T)  return  BOOLEAN; 

-- |  where  . . . 

After  the  where  delimiter,  the  user  enters  his  definition  of  the 
notion  “sorted.”  The  user  may  supply  a  (virtual)  body  for  this 
function,  which  could  he  used  to  test  arrays  for  sortedness. 

Anna  has  other  annotations  such  as  propagation  and  context 
annotations,  which  we  don’t  discuss  here. 


Modifying  Anna 

Anna  is  intended  to  support  both  formal  verification  (proof)  and 
run-time  testing.  Our  efforts,  and  our  modifications  of  Anna, 
are  directed  exclusively  toward  proof. 


Avoiding  reduction  to  Ada  The  current  Anna  reference 
manual  defines  the  semantics  of  Anna  and  of  its  assertion  lan¬ 
guage  by  reducing  them  to  Ada  semantics  [Anna  80].  Although 
the  meaning  of  Anna’s  assertion  language  need  not  be  stated 
computationally,  the  reference  manual  gives  the  meaning  of  each 
annotation  in  terms  of  values  computed  by  Ada  code.  There¬ 
fore  one  cannot  provide  the  semantics  for  or  the  logic  of  Anna’s 
assertion  language  without  first  providing  a  semantics  for  Ada. 
Wc  give  a  meaning  to  the  assertion  language  that  is  independent 
of  the  semantics  of  Ada. 


Unprovable  annotations  Certain  Anna  annotations  cannot 
be  proved  solely  from  the  definition  of  Ada,  whether  they're 
true  or  not.  1  ic  annotation  “if  the  stack  is  full  push  prop 
agates  stack.f  11”  is  an  example.  Before  push  can  execute 
raise  stack_fu  ’1  a  storage  error  or  numeric  overflow  may  or 
rur.  The  possibility  of  such  implementation-dependent  events 
is,  as  far  as  the  verifier  is  concerned,  an  act  of  God  (and  is 
equally  mysterious). 

We  change  our  interpretation  of  some  of  the  unprovable  anno¬ 
tations  to  make  them  more  useful  For  example,  we  qualify  all 
annotations  by  the  implicit  hypothesis  that  no  storage  error  or 
numeric  error  occurs. 


Erroneous  behavior  If  one  thinks  of  Anna  as  being  defined 
by  actual  execution  of  checking  rode,  t  hen  there  is  no  direct  way 
in  which  to  state  that  certain  executions  are  erroneous  since 
they  manifest  themselves  by  differences  in  execution  under  dif¬ 
ferent  compilers.  PolyAnna  lias  safeguards  built  in  that  prevent 
us  from  certifying  erroneous  programs. 


Partial  correctness  Anna’s  out  annotations  have  the  inter¬ 
pretation:  if  the  sropi  is  exited  normally,  then  the  out  anuota 
tion  is  true  upon  exit.  T  here  is  no  way  to  say  that  a  subprog!  am 
will  tel  minute  normally.  Techniques  of  proving  termination  foi 
deterministic  sequential  programs  are  well  under-stood,  and  we 
include  (hem  in  Poly  Alina. 
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Semantics  of  virtual  functions  In  the  current  description 
of  Anna  the  semantics  of  virtual  functions  is  informal.  A  virtual 
function  can  be  supplied  with  a  body,  if  one  wishes  to  generate 
checking  code  for  annotations  that  refer  to  the  virtual  func¬ 
tion.  However,  the  body  does  not  define  tin-  meaning  of  the 
virtual  function;  there  is  no  way  to  say  in  Anna  that  the  body 
“correctly”  implements  the  annotations  of  the  virtual  function. 
“Consistency"  is  not  sufficient.,  since  a  body  that  never  termi¬ 
nates  on  any  input  is  consistent  with  any  annotation  (excepting 
strong  propagation  annotations). 

PolyAnna’s  virtual  functions  are  purely  definitional  entities. 
Properly  annotated  virtual  functions  we  translated,  without 
appeal  to  Ada  semantics,  into  constructors,  which  are  strings 
of  our  logical  language.  A  well-formed  constructor  denotes  a 
partial  function,  and  associated  with  it  arc  rules  of  inference 
that  define  the  meaning  of  that  function.  For  example,  there  is 
a  family  of  constructors  that  define  functions  by  recursion.  The 
logical  details  are  contained  in  [ORA  871)]  and  [ORA  87c], 

Expressiveness  We  find  it  convenient  to  increase  the  expres¬ 
siveness  of  the  annotation  language  by  generalising  several  of 
the  Anna  constructs,  including  quantifiers,  tests  for  definedness, 
and  successor  states. 

Quantifiers  Anna’s  logical  quantifiers  are  unusual.  In  Anna, 
“for  all  x,  P(x)"  is  true  if  there  is  no  value  of  r  for  which  P(-r)  >s 
false.  Otherwise,  “(or  all  x,  P(x)”  is  false.  (In  Anna,  quantified 
expressions  are  never  undefined.)  So,  for  example,  “for  all  x, 
x  =  1/0”  is  true.  This  is  convenient  and  compact  foi  willing 
equational  axioms,  when  one  means  to  say:  the  equations  are 
true  whenever  all  their  constituent  terms  are  defined.  The  rules 
of  inference  obeyed  by  Anna’s  quantifiers  are,  unfortunately,  not 
very  convenient.  For  example,  “for  all  x,  P(x)"  is  not  equivalent 
to  a  conjunction  of  the  values  of  P(x)  for  all  possible  values  of 
x.  In  addition,  Anna’s  quantifiers  are  not  monotone  operators 
(see  [Stoy  77]). 

An  expressive  monotone  language  is  desirable  for  the  formu¬ 
lation  of  recursive  definitions.  The  PolyAima  quant  burrs  ate 
monotone,  and  tire  more  expressive  than  the  Anns  quantifiers. 
We  can  define  Anna’s  quantifiers  in  PolyAitna'x  logical  lan¬ 
guage. 

Definedness  tests  V x  is  a  program  variable,  the  Anna  attribute 
X* DEFINED  has  value  TRUE  if  x  has  been  initialized,  and  other¬ 
wise  has  value  FALSE.  If  e  is  an  expression  that  is  not  a  variable, 
then  e 'DEFINED  is  illegal.*  It  is  convenient  to  make  an  analogy 
between  an  uninitialized  variable  and  an  expression  that  failr- 
to  denote  a  value  (because  its  evaluation  fails  to  terminate, 
terminates  exceptionally,  or  is  erroneous).  In  our  formalism 
e’DEFINED  is  legal  for  any  expression . ' 

Successor  states  In  Anna,  the  values  of  the  local  variables  of  a 
package  make  up  the  stale  of  the  package.  Anna  uses  a  proce¬ 
dural  notation  for  naming  package  states:  for  instance,  5(F,  £/] 

'Although  it  it  straightforward  tu  imph-mpnt  a  tes;  for  x'DEFINED  when, 
x  is  a  variable,  there  is  no  general  w?.y  In  test  an  arbitrary  expression  for 
definedness  short  of  attempting  to  evaluate  it  -  but  that  evaluation  may  not 
terminate,  may  be  erroneous,  or  may  change  the  flow  of  control  by  raising 
an  exception 

•We  actually  use  a  different  notation 


is  the  name  of  the  state  that  results  from  state  5  after  invoca- 
ti  >n  of  P  and  Q  (in  that  order)  provided  that  both  invocations 
terminate  normally.  If  either  terminates  exceptionally,  there  is 
no  Annn  name  for  the  state  that  results.  We  extend  Anna  so 
that  all  reachable  package  states  have  names. 

Concreteness  By  design,  Anna  assertions  are  “close  to  the 
rode.”  Although  a  specification  like  “this  operating  system  is 
secure’’  may  ultimately  he  reducible  to  a  large  collection  of  cm 
bedded  assertions  about  the  relations  of  program  variables  to 
one  another,  the  connection  between  those  assertions  and  the 
original  specification  will  he  highly  obscure.  The  difficulty  of 
relating  a  comprehensible  specification  to  what’s  actually  been 
proved  about  the  program  is  well  known  and  is  common  to  all 
assertional  systems.  We  expert  to  ameliorate  this  situation  by- 
providing  some  modular  specification  mechanisms  in  high-level 
PolyAima,  an;  gous  to  the  mechanisms  of  LaKOII  [Gut  tag  85] 

Subordination  to  Ada  syntax  Anna's  conservative  syntax, 
which  essentially  follows  Atla’s,  is  useful  in  many  ways:  users 
with  a  knowledge  of  Ada  encounter  relatively  few  novelties;  the 
possibility  is  left  open  that  Ada  tools  may  be  modifiable  into 
Anna  tools;  the  job  of  generating  cheeking  code  is  more  straight¬ 
forward.  On  tixe  other  hand,  Anna  thereby  inherits  some  of 
Ada's  compromises.  For  example,  if  private  types  air  declared 
in  a  paekagt ,  Ada  requires  that  their  implement. at  ions  be  given 
in  the  private  part  of  the  p.iekage;  so,  therefore,  does  Anna.* 
Such  implementation  detail:,  .ire  precisely  what  a  sjn'wfiiuiiou 
language  wishes  to  abstract  away  from. 

Here  is  a  more  esoteric  example,  for  Anna  aficionados.  Cot; 
sider  the  problem  of  constraining  generic  formal  subprogram 
paraineteis.  Let  sort  be  a  generic  sorting  package.  We  wish 
to  constrain  the  formal  parameter  "<"  by  requiring  it  to  rep¬ 
resent  a  total  order.  Supp  .so,  further,  that  instead  of  writing 
out.  the  whole  definition  of  "total  order”  we  wish  to  import  its 
definition  from  a  predefined  library  of  sorting  concepts  and  the¬ 
ory,  a.  generic  package  railed  order. concepts.  To  do  so  would 
require  instantiating  the  order. concepts  package  with  "<"  at 
some  point,  in  the  generic  formal  part  of  sort.  Such  tin  instanti¬ 
ation  is  not  legal  Ada  (and,  therefore,  not  legal  Aim  t),  generics 
are  not  treated  as  first-class  objects.  There  is  no  concept  util 
difficulty  with  this  instantiation;  it  is  proscribed  bemuse  it  is 
beyond  the  compiler  writer’s  art.  We  expect  that  full  l’olyAima 
will  not  be  so  tightly  bound  to  Ada  syntax. 

Limitations 

Our  first  implementation  of  the  ground  floor  will  omit  eonetii 
rency',  and  will  probably  omit  any  special  facilities  fin  repre¬ 
senting  interaction  with  devices  (in  this  we  include  I/O),  or  for 
getieiies. 

Lessons  learned  from  predecessors 

We  have  learned  a  great  deal  from  Anna  and  have  tried  to  assess 
the  ways  in  which  it  must  be  modified  to  suit  our  special  pur¬ 
poses.  We  have  also  learned  from  extensive  experience  with  the 

‘This  requirement  makes  possible  separate  compilation 
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FDM  .1)1(1  Gypsy  systems,  and  from  a  more  modest  iicqunin 
timer  with  EllDivl.  (See  (FDM  SO],  [Gypsy  SC],  [ElIDM  SO].) 
VVe  describe,  below,  ways  in  which  wo  hope  to  improve  on  them. 

Justifying  assertional  reasoning 

To  use  the  assertional  strategy,  we  must  provide  a  way  to  re¬ 
duce  specified  programs  to  formulas  in  an  assertion  language. 
The  method  of  reduction  is  called  an  axiomatic  mnaniicx.  We 
must  also  provide  sound  logical  rules  for  manipulating  forum 
las  in  the  assertion  language.  The  axiomatic  semantics  should 
lie  justified  against  a  mathematical  definition  of  the  meaning  of 
the  programming  language,  and  the  logical  rules  should  be  jus¬ 
tified  against  a  mathematical  definition  of  the  meaning  of  the 
assertion  language. 

At  this  time  Ada  lias  no  mathematical  definition.  Although  a 
formal  definition  of  Ada  has  recently  been  completed,  it  has 
no  official  standing;  it  does  not  yet  count  as  a  semantics  for 
Ada  [DDC  87].  The  definition  is  very  complex,  and  we  do  not 
plan  to  justify  our  axiomatic  semantics  against  it. 

By  extending  and  amending  [llarr  84],  we  have  formulated  a 
many-sorted  first -order  assertion  language  in  which  expressions 
may  he  undefined,  the  collection  of  sorts  may  he  declared  to 
have  any  given  structure  of  subsorts,  and  the  domains  modelling 
the  sorts  may  he  empty.  Under  a  straightforward  mathematical 
definition  of  the  meaning  of  1  Isis  language  our  rules  of  proof  arc 
sound  and  deductively  complete.*  The  full  Ada  type  structure 
(excepting  task  types)  can  he  translated  into  this  language  The 
translation  is  demonstrably  correct  with  respect  to  our  formal 
model  of  the  Ada  types.  (Some  restrictions  apply;  we  do  not 
model  implementation- dependent  attributes,  and  we  forbid  cer¬ 
tain  kinds  of  mildly  pathological  declarations.  For  example,  an 
array  declaration  with  index  type  equal  to  the  whole  of  INTEGER 
is  disallowed.) 

We  define  the  meaning  of  the  assertion  language  by  defining  the 
meaning  of  “formula  ip  is  satisfied  in  state  a  on  the  hypothesis 
that  the  annotations  Ann  are  true.”  The  notion  of  hypothetical 
satisfaction  is  a  way  of  modularising  proofs;  the  hypotheses  ill 
question  are  the  assumptions  that  certain  routines  (  died  on 
obey  their  specifications. 

Incremental  verification 

The  verification  environments  we  know  work  in  hatch  mode. 
The  user  writes  a  program,  supplies  appropriate  assertions,  and 
then  submits  it  all  to  the  system,  which  generates  verification 
condition s:  a  list  (sometimes  large)  of  formulas  in  the  assertion 
language  whose  truth  is  sufficient  to  imply  that,  the  program 
satisfies  its  specifications.  The  verification  conditions  must  then 
he  shown  to  hold. 

The  drawbacks  of  batch  processing  arc  well  known.  When  a 
mistake  is  discovered  the  whole  job  must,  as  a  rule,  be  resub 
mitt <’d  and  much  correct  work  may  have  to  be  redone.  The 
relation  between  the  specifications  the  user  write  and  the  veri 
timtion  conditions  lie  sees  may  be  obscure.  Intermediate  stages 
of  verification  condition  g(  :u  ration  are  not  observable  and  then' 

•Must  i-xiMlng  system,  use  :L-,.rrt lull  languages  with  rules  of  infrrell.'i' 
1 1  i  a  t  are  logically  liiu-oiilnl  (unite  muepemlent  of  any  consul. -rat  axis  of  pro 
graniining  semantics)  liecausc  they  handle  undefined  expressions  uicorrertly. 


is  no  wav  to  tell  that  verification  conditions  are  get  ting  unman 
ageably  complex  until  it  is  too  late. 

Inn  eluent  id  ( ompilcrs  and  syntax-directed  editors  are  becoming 
mol e  widely  available  and  techniques  for  building  them  arc  he 
coming  well-known.  These  techniques'  should  allow  ns  in  build 
a  verification  environment  ill  which  incomplete  programs  can 
he  partially-  verified,  in  wind)  verification  conditions  are  under 
st  amiably  related  to  the  rode,  ami  which  duoctjy'  supports  the 
methods  of  [Cries  83]  and  [Dijk  SG] . 

Consider,  for  example,  a  simple  while  loop,  guarded  hv  condi¬ 
tion  b.  Suppose  for  simplicity’s  sake  that  there  is  no  otliet  exit. 
The  standard  while-loop  rule  del  ermines  the  effort  of  execution 
of  the  loop  solely  from  tip;  condition  b  and  n  user-supplied  iu 
variant  I,  wl  irh  is  restored  by  cadi  circuit  of  the  loop:  the 
effect  of  the  loop  is  characterized  by  the  fact  that  on  exit  the 
invaliant  I  remains  true  while  the  guard  b  is  lalxe.  The  user 
should  be  able  to  supply  the  guard  and  tlu*  invariant  of  a  loop 
and  then  complete  as  much  of  the  rest  of  the  program  as  he 
likes,  leaving  the  loop  body  to  be  filled  iu  Inf  er. 


The  peculiarities  of  Ada 

There  is  little  hope  of  verifying  arbitrary  Ada  programs.  Sur¬ 
veys  such  as  [OHA  85],  [Good  80a],  and  (Good  80b]  list  many 
difficulties.  Here  we  review  some  of  the  unusual  features  of  Ada 
and  describe  what  wo  do  with  them. 

Program  errors  Ada  introduce:;  two  special  categories  o! 
program  errors,  executions  that  are  “erroneous1’  or  contain  “in¬ 
correct  order  dependences."  These  errors  needn’t  be  caught  at 
com] file  time  and  needn’t  be  checked  for  at  run  time.  The  ef¬ 
fect.  (.1  an  erroneous  execution  is  completely  undefined  anti  that 
of  an  incorrect  order  dependence  varies  undesirably  from  com 
piler  to  compiler.  For  example,  an  attempt  to  read  the  value  of 
an  undefined  scalar  is  erroneous,  as  is  a  procedure  ca'.i  whose 
effect  depends  on  the  parameter-passing  mechanism.  A  proce¬ 
dure  call  whose  effect  depends  on  t  he  order  in  v/hicli  parameters 
are  passed  contains  an  incorrect  order  dependence. 

We  tlimk  it  essential  that  the  products  of  a  verification  i  nviion 
incut  contain  neither  erroneous  executions  nor  incorrect  order 
dependences.  Forbidding  these  errors  also  simplifies  tie’  res!  of 
Ada’s  semantics  and  should  make  verification  more  tractable. 
Some  of  these  simplifications  are  discussed  below. 

Predefined  exceptions  We  prove  nothing  about  the  prede¬ 
fined  exceptions  STORAGE.  ERROR  and  NUMKRIC.ERROR.”  All  ver 
ifiralions  are  qualified  by  the  hypothesis  that  neither  of  these 
oeeurs.  Since  an  implementation  may  choose  not  to  report  over¬ 
flows  we  must  assume  in  addition  that  no  unreported  overflow 
occurs. 

One  ran  in  principle  show  that  certain  predefined  exceptions, 
such  as  CONSTRAINT. ERROR,  are  never  raised.  We  will  always 
requiie  pi  oof  that  they  are  never  raised -This  forces  a  style  on  t  hr 
progi anuiier  that  forbids  use  of  CONSTRAINT. ERROR  as  normal 
pmetice  e.g.,  as  the  intended  exit  from  a  loop. 

"home  exceptions  to  this  arc  described  in  [ORA  R7aj. 
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Optimisations  Wc  have  shown  elsewhere  that,  if  a  compiler 
makes  full  use  of  tiie  allowed  optimizations  to  reorder  coinputa- 
tions,  it  is  impossible  to  guarantee  such  properties  of  the  com¬ 
piled  code  as  "no  variable  is  read  before  it  is  written"  [ORA  85). 
We  ■  in  undertake  to  verify  the  effects  only  of  prugiams  executed 
in  the  standard  order. 


Restricting  Ada 

Hen;  arc  some  of  the  siinplifkr.tions  we  wish  to  impose  on  the 
Ada  programs  we  undertake  to  verify. 


•  We  do  riot  plun  to  include  real  arithmetic  or  the  implemen¬ 
tation-dependent  parts  of  the  language  even  in  full-scale 
Poly  Anna. 

♦  As  noted  above,  we  treat  the  raising  of  ali  predefined  ex¬ 
ceptions  as  mistakes.  tVc  wash  our  hands  of  some  such 
mistaken  (WJHSRICJS&ROft,  STO&AGE.ERROP.)  and  require 
proof  that  the  others  will  not  occur 

»  In  Older  to  prevent  program  errors  resulting  from  ini 
proper  parameter  passing,  we  forhid  certain  instances  of 
aliasing  among  the:  actual  parameters  of  any  procedure 
call  (anti  between  actual  parameters  and  glohids).  When 
this  is  not  immediately  guaranteed  by  static  analysis,  wr 
require  a  proof  that  the  restriction  ha-s  been  obeyed.  This 
h«s  the  additional  advantage  of  greatly  simplifying  the 
logic  of  the  procedure  call  proof  ruins. 

*  W'e  tdopt  the  Anna  requirement  that  packages  have  the 
hidden  sir.lt'  property  [Anna  86],  which  guarantees,  essen¬ 
tially,  that  the  effects  of  package  operations  depend  only 
on  the  parameters  to  the  operation  and  on  local  variables 
of  the  package  not  on  externally  vdsible  (and  therefor." 
externally  modifiable)  variables  or  on  variable:;  global  to 
the  package  This  makes  it  possible  to  specify  the  behav¬ 
ior  of  the  package  in  isolation. 

*  In  order  to  avoid  program  errors  resulting  from  indiscrim¬ 
inate  use  of  side  effects  we  forbid  the  use  of  functions  with 
side  effects  unless  static  analysis  rules  out  tile  possibility 
ol  a  program  error. 


Many  other  restrictions  are  matters  of  style  as  much  a-  of  pro 
grammiug  language  theory  for  there  is  little  hope  of  verifying 
completely  arbitrary  programs  in  any  language.  We  hope  that 
incremental  verification  will  naturally  impose  on  idle  iwr  a  stylo 
arrenable  to  verification:  a  style  in  which  one,  in  effect,  outlines 
the  proof  of  a  routine  and  then  implements  the  proof  outline. 


Po!yn.nna 

We  have  so  far  described  a  system  with  capacities  analogous  to 
those  of  Gypsy  or  EHDM,  but  with  certain  important  improve¬ 
ments  made  possible  by  some  new  theory  and  new  techniques 
in  building  software  environments.  To  exploit  more  fully  the 
resources  of  Ada  requires  much  more,  and  that  is  the  purpose 
of  lull  PolyAnna.  Our  account  is  necessarily  prospective  and  is, 
to  some  extent,  a  firm  endorsement  ol  motherhood. 


A  higher-order  polymorphic  language 

Higher  type  ations  are  implicit  in  Ada.  A  generic  func¬ 
tion,  f;.u  example,  can  be  thought,  of  as  a  higher  type  oper¬ 
ation  tb  accept y  types  and  subprograms  as  parameters  ami 
returns  a  function.  A  generic  package  is  a  high-r  type  opera 
tion  that,  returns  a  pnek-sge.  packages  bung  objicts  that  la. long 
to  rather  complicated  type- .  Genei.U.s  are  not  only  high  t  type 
operations,  l.ul  polytnoiplue:  a  formal  pauvaeter  can  be  validly 
matched  by  objects  of  many  types,  or  even  by  types  themselves. 
The  Ada  attributes,  included  principally  to  facilitate  the  writing 
of  generics,  are  aiso  higher  type,  polymorphic  opemtions. 

For  practical  reasons  Ada  treats  generics  as  macros  ruth-'  r  than 
full-fledged  operations.  The  esoteric  difficulty  foi  Anna  sketched 
earlier,  stemming  from  Ada’s  inability  tv  instant int-:  one  generic 
at  a  particular  place  in  the  declaration  of  another,  arises  pre¬ 
cisely  because  Ada  docs  not  treat  generics  as  “first-clans  oh 
jeets”  on  n  par  with  vaiiabdes  foi  even  on  ,i  par  with  second -class 
objects  like  functions).  Ada  docs  riot  pursue  its  own  logic  to  a 
natural  conclusion,  which  would  require  generic.-  th-nnselves  to 
be  typed  objects  and  accept  as  parameters:  packages,  package 
and  type-returning  operations,  the  types  of  function  u-turniug. 
operations,  et  cetera.  Poly  Anna  will,  in  the  manner  of  ordinary 
mathematics,  draw  this  conclusion  by  making  all  sue::  entities 
first  class. 

Conclusion 

An  Ada  verification  environment  offers  the  chain. o  to  put  veri 
fied  rode  into  general  use.  Wc  hops  to  have,  a  inuring  system, 
capable  of  verifying  programs  specified  in  a  modest  hut  use¬ 
ful  formal  specific*! ion  language  (a  variant  of  Anna),  by  fall, 
of  I9SS.  It  is  based  on  well  established  ti-oluiiques  of  asscr- 
tional  reasoning  about  programs  and  is  intended  to  improve 
on  its  ancestor.,  in  that  the  underlying  logic  ot  tin-  assertion 
language  is  fouually  based  and  demonstrably  sound,  and  that 
proofs  of  prugiams  can  he  done  incrementally,  in  step  wi<  h  Unit 
development.  Exploitation  of  Ada’s  tiiecimntsnis  for  abstraction 
requite;;  extension  of  this  assertion  language.  possibly  to  a  lan¬ 
guage  that  is  both  higher-type  am!  polymorphic. 
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Second,  after  the  TCB  receives  the  Procedure,  the  TCB  validates 
it  to  ensure  that  all  internal  structures  and  pointers  are  self- 
referencing.  Essentially,  the  procedure  is  viewed  as  untrusted  by 
the  TCB,  so  it  is  impossible  for  the  Procedure  to  violate  the 
security  provisions  of  the  model.  Next,  the  TCB  performs  a 
discretionary  access  check  on  the  databases  and  tables  refer¬ 
enced  in  the  Procedure.  If  any  of  these  steps  fail,  the  error  is 
audited  and  the  host  is  notified  that  the  command  could  not 
complete.  If  these  cheeks  succeed.  Query  Execution  continues  to 
execute  the  Procedure. 

When  data  arc  selected  from  the  database,  the  TCB  returns 
them  through  the  Mandatory  Security  Check.  Each  security 
label  on  each  row  is  compared  to  the  login-level  clearance 
associated  with  the  user  process.  If  the  user’s  security  level  is 
greater  than  or  equal  to  the  security  level  of  the  row,  the  row  is 
saved  by  Query  Execution,  and  is  returned  to  the  host.  Other¬ 
wise,  the  row  is  ignored  and  (he  selection  process  continues.  The 
data  row ,  along  with  the  security  level  of  the  row  and  a  row-level 
CRC  is  then  returned  to  the  host. 

When  data  arc  inserted  or  updated  in  the  database,  the  TCB  uses 
the  Update  page  CRC  and  L  abel  code  to  perform  the  operation. 
The  Update  Page  CRC  and  Label  code  computes  the  CRC  for 
the  updated  data  page  and  uses  the  user’s  login  security  level  to 
update  the  row’s  new  security  label.  Finally,  it  confirms  the 
logical  consistency  of  the  row  and  the  logical  placement  of  a  row 
on  a  memory  page. 

SUMMARY 

The  SYSDS  design  uses  a  reference  monitor  approach  to  system 
security  to  achieve  a  robust  multilevel  secure  DBMS  without 
sacrificing  performance.  It  utilizes  rows  as  the  mandatory 
security  object,  and  databases  and  tables  as  the  discietionary 
security  objects.  This  enables  the  system  design  to  take  advan¬ 
tage  of  existing  Sybase  DataServcr  software  whiic  introducing 
new  security  mechanisms.  The  newly  re-architeeted  product  is  a 
major  departure  from  the  basic  DataScrver  architecture,  but 
significant  performance  features  of  the  commercial  system  have 
been  maintained,  indicating  that  the  SYSDS  approach  will  meet 
its  goals  of  multilevel  security  with  excellent  performance. 

Most  of  all,  the  SYSDS  is  intended  to  be  a  commercially  viable 
system,  able  to  be  used  in  a  number  of  government,  military, 
and  private  sector  data  processing  sys'ems.  The  approach 
addresses  the  concept  of  data  integrity  and  additionally  intro¬ 
duces  the  concept  of  TCB  integrity,  since  total  system  integrity  is 
a  major  concern  in  any  DBMS  application.  Because  of  these 


points,  it  is  felt  that  the  SYSDS  approach  provides  a  solution  to 
the  multilevel  DBMS  problem 
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1 . 0  DISASTERS --LARGE  AND  SMALL--ARK 
CONTINGENCIES 

When  we  think  of  computer  disasters,  we 
tend  to  think  of  the  large-scale  disas¬ 
ters:  hurricane,  tornado,  earthquake, 
or  fire.  Few  of  us  are  surprised  to 
hear  that  most  of  all  disabling  "dis¬ 
asters"  involve  either  water  or  fire. 
Several  examples: 


Location 

Year 

Cause 

State  of 

1973 

Flood  (river) 

Pennsylvania, 

Harrisburg 

Census  Bureau, 

1980 

Sprinkler 

Maryland 

System 

China  Lake 

1985 

Flash  Flood 

Weapons  Center, 

Cali fornia 

Two  of  these  events  involved  natural 
catastrophes,  the  third  (Census)  in¬ 
volved  a  combination  of  human  error  and 
mechanical  failure.  Outage  times  varied 
from  3  weeks  (to  partial  restoration)  to 
several  months  [8). 

However,  although  very  few  computer 
centers  have  had  to  fully  recover  from  a 
disaster  as  massive  as  those  listed 
above,  most  centers  have  had  to  recover 
from  a  small  di saster--again,  most  often 
resulting  from  human  error,  fire,  or 
water  ]9],  In  my  personal  experience, 
every  data  center  that  1  have  worked  for 
or  managed  has  had  a  flood,  with  plumb¬ 
ing  (broken,  inadequate,  or  nonexis¬ 
tent)  involved  in  every  case.  (One 
reference  reports  that  90  percent  of 
outage  contingencies  are  caused  by 
people--mostly  by  accident  oi  ignorance.) 

Because  of  the  likelihood  of  an  outage 
resulting  from  an  event  other  than  a 
catastrophe,  we  will  refer  to  the 
"disaster"  recovery  planning  process  as 
contingency  planning  throughout  the 
paper.  This  term  properly  emphasizes 
the  wide  range  of  use  of  this  type  of 
planning. 

The  need  for  contingency  planning  is 
widely  reported  [16,21].  In  a  key  1978 
study,  the  University  of  Minnesota 
Management  Information  Systems  Research 
Center  reported  that  many  American 
businesses  could  not  stay  in  business  if 
their  critical  computer  systems  were  off 


line  for  7  Lo  14  days  1 16 ]  .  In  198b, 
the  General  Accounting  Office  study 
reported  that  only  9  of  2S  computer 
systems  studied  had  existing,  tested 
contingency  plans  [15].  The  requirement 
goes  beyond  business  prudence  into 
regulation  in  many  cases.  The  federal 
government  policy  (Office  of  Management 
and  Budget)  requires  a  contingency  plan 
for  government  facilities  [15].  Recently, 
the  Comptroller  of  the  Currency  re¬ 
iterated  its  requirement  that  "national" 
banks  have  a  contingency  plan  in  place 
for  critical  information  systems  [19]. 

This  paper  outlines  a  method  of  imple¬ 
menting  a  contingency  plan  in  a  single, 
relatively  short  effort.  The  approach, 
called  fast  track,  is  to  develop  a 
workable  plan  by  dealing  only  with  the 
most  critical  systems  first.  This 
approach  works  best  because  it  quickly 
leaches  the  crucial  phase —  testing.  It 
often  proves  less  costly  because  the 
critical  systems  can  be  run  on  a  smaller 
configuration  than  that  required  for  all 
computer  applications.  It  permits  a 
recovery  plan  to  be  developed  and  tested 
within  a  year;  we  target  for  6  months. 


2 . °  FAST  TRACK 

The  fast-track  approach  to  contingency 
planning  is  based  on  the  principle  of 
restricting  the  set  of  pioblems  to  be 
resolved  wherever  possible.  It  is 
predicated  on  three  key  beliefs:  (1) 
restoration  of  a  part  of  an  organi¬ 
zation's  information  systems  will  be 
better  than  none;  (2)  a  contingency 
recovery  plan  must  reach  the  test  phase 
to  demonstrate  the  full  extent  of  an 
organization's  vulnerability  and  to 
develop  managements'  confidence;  and  (3) 
a  company  can  (in  general)  afford  to 
backup  only  a  subset  of  its  data  and 
applications . 

2 . 1  Management  Commitment 

Management  commitment  is  the  key  element 
to  all  contingency  recovery  planning 
| 3 ] .  In  our  recommended  fast-track 
approach,  it  is  the  first  phase. 
Depending  upon  the  breadth  of  the 
computer  systems  beinq  analyzed,  the 
management  to  be  involved  will  range 
from  the  head  of  a  department  ( for  a 
departmental  system),  to  a  division 
general  managei  (in  a  divisionalized 
company),  to  the  chief  executive  officer 


373 


(CEO).  The  key  characteristic  of  the 
manager  to  make  the  decision  is  the 
ability  to  recognize  the  computer 
application  as  key  to  the  organization's 
(and,  therefore,  the  manager's)  health. 

To  gain  management's  commitment,  the 
risk  to  the  company  of  loss  of  infor¬ 
mation  and/or  information  processing 
must  be  put  in  terms  of  the  company's 
ability  to  perform  or  in  terms  of 
potential  dollars  lost.  Once  management 
recognizes  this  risk,  they  must  agree  to 
a  budget  for  development  and  implemen¬ 
tation  of  a  contingency  plan  and  for  the 
ongoing  maintenance  of  the  plan  (and 
enhancement  if  necessary).  This  is  a 
significant  challenge  to  many  managers, 
who  often  find  themselves  two  levels  (or 
more)  below  the  level  of  the  k<v  manage¬ 
ment  to  be  involved  and  in  a  <  mate  of 
reduced  budgets . 

The  fast-track  method  isolates  the 
critical  applications  and  their  vulner¬ 
ability  by  applying  two  rules: 

•  Limited  extent.  Establish  the 
extent  of  contingency  at  the 
walls  of  the  computer  room  and 
develop  the  vulnerability  of 
that  room  being  disabled. 

•  Limited  duration.  Establish 
the  extent  of  the  contingency 
outage  (to  successful  restor- 
ation--on  site  or  at  a  restor¬ 
ation  site)  at  7  days. 

By  applying  the  first,  rule,  the  vulner¬ 
ability  (in  terms  of  events  per  100 
years,  the  standard  measure)  is  real¬ 
istically  high  because  of  combination  of 
catastrophe  (major  storm,  flood,  major 
fire)  with  the  ordinary  (human  erroi , 
small  fire,  broken  pipes,  clogged  sewer 
lines).  By  applying  the  second  rule, 
the  applications  that  are  exposed  are 
only  those  that,  are  truly  cutical 
(likely  to  result  in  major  financial 
loss  to  the  company)  and  most  recogniza¬ 
ble  as  such  by  senior  management  ( 1 ] .  A 
key  element  in  identifying  the  appli¬ 
cations  is  establishing  recovery  time 
criteria  (i.e.,  the  maximum  time  that 
the  application  can  be  out  of  opera¬ 
tion  ) . 

The  process  ol  risk  analysis  should  be 
conducted  quickly  and  with  as  few  people 
involved  as  possible.  The  data  process¬ 
ing  manager  and  his  staff  can  develop 
the  first  draft  and  then  confirm  their 
findings  with  the  managers  responsible 
for  the  functions  supported  by  the 
critical  applications  exposed.  This 
group  of  managers  then  forms  the  team  to 
confront  senior  management  with  the  risk 
and  the  need  for  a  contingency  recovery 
plan.  (Note:  if  this  group  cannot 
agree  upon  the  criticality,  then  it  is 
unlikely  that  a  "sale"  can  be  made  to 
senior  management.)  Other  members  of 
the  organization  that  may  initiate  the 
risk  analysis  include:  the  manager  of 
security,  the  manager  of  the  function  at 
risk,  or  (best  of  all)  the  CEO.  In  all 


cases,  both  the  users  of  the  application 
and  data  processing  must  be  fully  in¬ 
volved.  (For  details  on  risk  analy¬ 
sis,  see  references  2  and  9.) 

Once  the  critical  applications  are 
identified,  and  senior  management, 
recognizes  the  company's  vulnerability, 
the  risk  analysis  team  (all  managers) 
must  gain  senior  management  commitment 
to  invest  in  a  contingency  plan  and  its 
ongoing  maintenance.  This  will  require 
a  commitment  to  deliver  a  plan,  ready 
for  testing,  in  a  fixed  amount  of  time. 
We  recommend  6  months,  in  four  phases: 


Staff 


Phase 

Required 

Time 

1  -  Management 

2-5 

4 

weeks 

Commitment 

2  -  Workable  Plan 

- 

Pass  1 

2-5 

4 

weeks 

Pass  2 

5-10 

5 

weeks 

3  -  Affordable 

2-5 

4 

weeks 

Plan 

4  -  Implemen¬ 

5-10 

9 

weeks 

tation  & 

26 

weeks 

Testing 

It  is  essential  that  this  commitment  be 
made  if  the  plan  is  to  be  completed. 
Otherwise,  the  plan  is  likely  to  fail 
due  to  budget  pressure,  change  in 
management  sponsorship,  or  worse, 
disillusionment  by  the  planning  team. 

2 . 2  Workable  Blau 

The  next  phase  in  the  fast-track  approach 
is  to  develop  a  workable  and  affordable 
plan.  Can  it  be  done?  We  believe  it 
can,  because  the  plan  should  only  target 
to  recovei  the  applications  that  are 
truly  critical  (i.e.,  identified  in  the 
first  phase)  and  for  contingencies  that 
are  limited  to  the  computer  room  itself. 

("Why?"  the  leader  exclaims.  "Shouldn't 
we  consider  the  secondary  applications 
(those  which  must  be  restored  within  two 
weeks)?  Shouldn’t  we  anticipate  a  major 
catastrophe  in  which  half  the  staff  is 
unavailable  to  support  the  recovery 
process?"  These  questions  are  reasonable. 
However,  the  fast-track  approach  does 
not  answer  them  at  this  time.  Fast 
track  is  targeted  to  develop  a  workable 
and  tested  plan  for  the  few  truly 
critical  applications  in  a  limited 
"catastrophe."  Once  a  successful  plan 
is  in  place,  it  is  the  author's  belief 
(and  experience)  that  secondary  (and 
even  tertiary)  applications  can  be 
accommodated  more  easily  and  at  less 
expense. ] 

The  process  of  developing  a  workable 
plan  is  described  briefly  below.  The 
list  of  references  provides  several 
sources  that  provide  superb  detail  foi 
this  phase  11,6,9,12,18,20).  The  key  to 
this  plan  is  a  two-pass  appioach:  the 
first  is  conducted  by  a  small  team;  and 
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the  second  by  the  team  of  key  players 

identified  in  step  S. 

1.  Clearly  define  the  range  of 
contingencies  that  are  being 
planned  for.  For  example,  if 
the  computer  room  is  destroyed 
(or  made  inoperable  for  a  week 
or  more),  what  is  the  effect  on 
the  telecommunications  network, 
what  is  the  effect,  on  the  onsite 
tape  and  disk  storage,  on  the 
lists  of  work  in  progress,  and 
on  operating  procedures? 

2.  Develop  profiles  of  the  critical 
applications:  required  computer 
peripherals,  disk  storage,  tape 
drives,  telecommunicatons 
requirements,  unique  operating 
system  features,  locally  developed 
operating  software  and  utilities, 
vendor  (and  third  party)  software. 
If  data  bases  are  involved:  who 
is  data  base  administrator; 

where  are  the  lists  of  updates; 
are  audit  tapes  used? 

3.  Review  operations  procedures, 
assure  that  they  are  up  to  date, 
and  list  changes  that  would 
minimize  the  exposure  to  any  of 
the  expected  contingencies. 
Especially  important  are  the 
offsite  storage  procedures  |4| 

(e.g  ,  storage  of  duplicate 
procedures  offsite,  more  fre¬ 
quent  backups  of  critical  files, 
maintenance  of  backup  records  in 
duplicate,  etc.). 

4.  Review  the  computer  center, 
central  telecommunications 
network  components,  and  data 
library  for  ways  in  which  loss 
of  one  can  be  segregated  from 
the  others. 

5.  Establish  a  recovery  team  roster 
made  up  of  the  key  operations, 
systems,  telecommunications, 
support,  and  and  applications 
users'  supervisors  and  managers. 
Identify  those  that  may  be  at 
risk  (e.g.,  injured  or  dead)  if 
one  of  the  (limited)  contingen¬ 
cies  occur.  For  all  individuals, 
select  alternates.  For  those  at 
risk,  select  secondary  alternates. 
(Note:  at  this  stage,  it  is  all 
right  to  use  the  same  individual 
for  more  than  one  role;  however, 
care  must  be  taken  to  avoid  the 
"all  eggs  ..."  syndrome.) 

t> .  Develop  most  likely  backup 

scenarios;  hot-site,  cold-site, 
full  redundancy,  mutual  backup 
arrangement,  etc.  (4, IB].  For 
each,  develop  a  telecommu¬ 
nications  backup  concept  (13). 
These  should  be  simply  sketched 
out.  At  this  point,  the  actual 
method  of  backup  will  not  be 
decided.  Only  the  fact  of 
backup  is  important  (and  its 


resulting  impacts  on  personnel, 
data  transfer,  telecommuni¬ 
cations,  and  pioccdures). 

7.  Develop  an  outline  for  the 
contingency  recovery  plan 
manual.  During  the  first  pass, 
this  outline  should  be  at  least 
as  detailed  as  that  shown  in 
Figure  2.01.  During  the  second 
pass,  draft,  sections  are  included 
where  they  can  be  fleshed  out. 

AL  the  end  of  the  first  pass,  the  team 
is  expanded  to  include  the  principal 
backup  members  identified  in  step  5. 

This  team  now  reviews,  criticizes,  and 
modifies  each  product  of  steps  1  through 
7.  Tlie  result  should  present  a  workable 
plan  containing  all  the  elements  required 
to  get  the  critical  applications  back 
into  operation.  The  result  does  not  yet 
address  cost,  the  actual  method  of 
backup,  or  the  time  it  would  take  to 
lecover.  However,  t.he  result  should 
identify  those  procedures,  elements  of 
room  layout,  and  application  requirements 
that  will  complicate  the  backup  process. 

in  terms  of  staffing,  this  phase  need 
not  be  too  expensive.  Many  of  the  steps 
can  be  carried  out  in  parallel.  The 
second  pass  can  be  staffed  by  the 
additional  members  without  removing  them 
from  their  current  responsibilities  in 
most  cases. 


1.  Introduction  and  Overview 

2.  Mobilization 

-  Notification 

Offsite  storage 

3 .  Operations  Recovery 

Organization 
Backup  facility 
Checklists 

4.  Management  Support  Team 

b.  Administrative  Support  Team 

6.  Site  Restoration 

7.  Maintenance  and  Testing 
B.  Team  Directory 

Figuie  2.01 

Contingency  Recovery  Manual 
(sample  table  of  contents) 


2 . 3  Affordable  Plan 

The  third  phase  of  the  fast-track 
approach  develops  the  action  plan  for 
achieving  a  plan  and  recommends  the 
best,  affordable  approach  to  backup.  It 
is  principally  a  task  of  cost  estimating 
and  problem  simplification.  It  aims  at 
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providing  a  backup  plan  that  will  meet 
the  budget  requirements  set  in  the 
management  commitment  phase  as  well  as 
the  recovery  time  parameters  required  by 
the  critical  applications. 

•  Cost  estimating.  The  possible 
backup  plans  aie  estimated  by 
reviewing  the  available  market 
options  for  backup  recovery. 

Once  these  are  known,  the 
telecommunications  backup  costs 
are  developed,  especially  those 
that  arc  ongoing  (e.g.,  dialup 
modems,  ACCUNET  reserve  "local 
loops,"  additional  network 
nodes).  At  the  same  time, 
offsite  data  storage  costs  are 
developed . 

•  Problem  simplification.  During 
phase  2,  it  is  likely  that 
several  problems  were  identified 
that  complicated  the  backup 
planning  or  added  expense  to  the 
backup  recovery  plan.  Examples 
of  these  are:  telecommunications 
and/or  data  storage  in  the  same 
room  with  the  computers;  special 
haidware  for  the  critical 
application  that  is  difficult  or 
expensive  to  duplicate;  loca] ly 
developed  software  options  or 
configuration-specific  aopl icati on 
featuies;  and  data  base  layout, 
that  combines  time-critical  data 

h  %  ft,  a  w  1  ^  1  A  1  «  f  waaim  rt  m  ♦  1  ft 
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referenced  data.  Now,  the  team 
identifies  changes  that  could 
mitigate  the  impact  of  these 
problems  on  the  backup  process . 

For  example,  it  may  be  cheaper 
to  build  fire  walls  between  the 
three  areas  of  the  computer  room 
than  to  plan  for  likely  destruc¬ 
tion  and  total  backup  of  all 
three  areas;  it  may  be  easier 
to  modify  the  application  and  to 
restructure  the  data  base  than 
to  duplicate  expensive  haidware 
or  restore  all  data  within  24 
hours . 

In  deteimining  the  full  cost  of  the 
ongoing  contingency  plan,  full  cost 
should  te  considered:  a  Contingency 
Planning  Manager  (a  minimum  of  one- 
quarter  of  a  person);  cost  of  updating 
the  manuals  at  least  annually;  cost  of 
offsite  storage  of  critical  application 
data;  duplicate  communications  equipment 
(and  data  links  if  required);  and  the 
cost  ol  having  the  backup  site  ready  and 
tested  (e.g,,  in  the  case  of  a  "hot- 
site"  this  is  usually  a  monthly  fee  that 
includes  testing  once  or  twice  a  year). 

2 . 4  Implementation  and  Testing 

At  this  point,  we  are  ready  to  imple¬ 
ment.  The  procedures  and  implementation 
of  the  offsite  data  backup,  telecommuni¬ 
cations  network  backup,  operations 
changes,  and  applications  changes  can  be 
cost  justified  and  proceeded  with  on 
their  own.  Each  will  bring  a  measure  of 


protection  that  likely  did  not  exist  in 
full  (or  part)  before.  Only  the  backup 
site  need  be  reviewed  again  for  cost 
benefit.  If  the  backup  site  fits  the 
original  forecast  budget  (and  already 
committed  to  by  senior  management), 
approval  to  proceed  should  he  forth¬ 
coming.  During  this  process  of  imple¬ 
mentation,  the  contingency  recovery 
manual  should  be  completed  and  readied 
for  use. 

Before  proceeding  on  the  backup  imple¬ 
mentation,  the  plan  should  be  quickly 
reviewed  by  the  full  team  for  "test- 
worthiness."  The  team  should  agree  that 
the  plan  will  work  as  tested.  As  soon 
after  the  backup  site  is  established, 
the  plan  should  be  tested  |  3 , 1 7  )  . 

During  testing,  an  independent  observer 
should  track  the  test  in  terms  of 
successes  and  failures.  At  the  end  of 
the  test  (or  at  the  point  that  the  test 
has  failed),  the  team  should  be  de¬ 
briefed  and  an  action  plan  put  in  place 
to  correct  the  major  shortcomings  of  the 
plan.  A  second  test  should  then  be 
scheduled  and  ttie  plan  verified. 

If  the  budget  will  not  cover  the  cost  ol 
establishing  a  backup  method  that  meets 
the  recovery  time  criteria  or  the 
application  requirements,  then  the  plan 
should  be  reviewed  witli  senior  manage¬ 
ment  .  They  should  agree  to  one  of 
several  conclusions: 

•  The  recovery  lime  criteria  are 
too  stringent. 

•  The  budget  is  inadequate,  or  the 
applications  involved  are  less 
critical  than  originally  deter¬ 
mined. 

•  The  systems  are  too  monolithic 
to  permit  backup.  In  this  case, 
either  redesign  of  the  appli¬ 
cations  or  redundant  systems  may 
be  the  only  solution. 

2 . b  The  Living  Plan 

Af  this  point,  the  company  (oi  organi¬ 
zation)  will  have  a  tested  and  working 
plan.  The  plan  should  now  be  reviewed 
for  its  limits  and  most  desirable 
extensions.  Several  have  been  discussed 
oi  alluded  to  previously: 

t  Extension  to  cover  loss  of  the 
complete  flooi  oi  building 

•  Extension  to  anticipate  the  loss 
of  key  personnel 

•  Inclusion  of  the  remainder  of 
the  critical  oi  near -cr itical 
app] icaf l ens . 

These  changes  do  not  have  to  be  made 
immediately,  hut  they  should  be  described 
in  sufficient  detail  so  that  management 
can  assign  priorities  and  consider  them 
for  inclusion  in  future  plans. 
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Just  as  important  is  the  review  of  the 
plans  for  computer,  telecommunications, 
and  applications  modifications.  The 
fast-track  process  of  contingency 
recovery  planning  should  bring  to  light 
those  critical  factors  that  can  be 
eliminated  wi th  changes  to  the  computer 
and  telecommunications  configurations 
and  redesign  of  software  and  data  base 
applications.  For  example,  future 
additions  to  the  computer  system  can 
attempt  to  achieve  redundancy  in  con¬ 
figurations,  especially  where  the 
configurations  can  be  separated  by 
enough  distance  to  reduce  the  chance  of 
both  centers  being  placed  out  of  com¬ 
mission  by  a  single  event.  In  another 
instance,  data  base  redesign  may  reduce 
the  critical  application  to  a  more 
transportable  size. 

Finally,  the  incorporation  of  the 
contingency  plan  procedures  into  the 
day-to-day  operations  is  essential 
(5,7).  As  new  applications  are  developed, 
they  should  be  tested  to  sea  if  they 
meet  the  requirements  of  being  declared 
critical,  and  if  so,  added  to  the  plan. 

In  the  meantime,  all  secondary  appli¬ 
cations  should  be  encouraged  to  store 
copies  of  software  and  recent  data 
offsite  to  ensure  their  recovery  (if  not 
immediate  availability). 


3.0  CONCLUSIONS 

The  need  for  contingency  recovety 
planning  is  clear  for  businesses  and 
organizations  whose  survival  depends  on 
computer  systems.  The  iast-track 
approach  provides  an  alternative  to  the 
traditional  approach  which  pulls  key 
people  off  their  day-to-day  jobs  and 
delays  the  demonstration  of  benefit  for 
1  to  2  years.  The  fast.-tiack  approach 
minimizes  expense  and  provides  flexible 
positioning  to  changing  computer  needs. 
The  following  conclusions  can  be  drawn 
from  this  iper. 

•  Disaster  planning  is  an  umbrella 
audit  of  all  procedures.  A 
tested  disaster  plan  and  its 
related  hardware,  software,  and 
services  is  a  form  of  insurance. 
As  in  the  case  of  insurance,  it 
does  not  have  to  be  exercised  to 
be  useful.  By  developing  the 
proper  insurance  program,  a 
company  actually  increases  its 
value.  A  disaster  plan  should 
be  viewed  as  lowering  risk  to 
customers  and  investors. 

•  Developing  and  maintaining  an 

operational  disaster  recovery 
plan  is  seen  as  an  expensive 
process.  However,  when  viewed 
foi  its  insurance  value,  and  as 
part  of  the  overall  data  center 
operations  process,  the  expense 
j.s  reasonable  and  often  has  a 
payback:  it  develops  confidence 

in  your  business  by  your  cus¬ 
tomers  . 


•  Commitment  and  support  from  top 
management  is  essential.  A 
disaster  recovery  plan  is 
recognition  that  the  data  center 
and  the  information  systems 
supported  by  the  center  are 
critical  corporate  resources.  A 
disaster  plan,  even  when  estab- 

3 ished  in  one  year,  is  a  long¬ 
term  program,  requiring  testing 
and  review  on  a  regular  basis. 

•  Critical  systems  identification 
is  the  first  step  to  the  detailed 
planning  process.  There  are 
usually  three  or  four  appli¬ 
cations  that  are  key  to  a 
company's  survival.  They  are 

the  ones  that  must  continue  in 
operation  in  event  of  a  disaster. 

•  The  planning  process  is  a 
continuous,  iterative  process. 

New  and  existing  applications 
should  be  reviewed  annually  for 
inclusion  (or  removal)  from  the 
plan  The  plan  itself  should  be 
tested  periodically  and  modified 
when  necessary. 

If  a  contingency  plan  is  not  in  place 
today,  the  first  plan  should  be  put  into 
action  as  soon  as  possible  and  updated 
iteratively  until  management  is  satisfied 
that  adequate  protection  exits  for 
critical  business  applications,  with 
the  trend  toward  increased  use  of 
automation,  the  dependence  of  critical 
business  operations  on  the  data  center 
will  increase.  With  the  tendency  toward 
distributed  (departmental  and  work 
group)  computing,  the  need  foi  a 
corporate-wide  understanding  of  contin¬ 
gency  planning  will  grow. 
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RETURN  TO  NORMALCY:  ISSUES  IN  CONTINGENCY  PROCESSING 


Thomas  C.  Judd 
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Much  time  and  many  words  have  been  shared 
regarding  data  processing  security  measures 
and  the  recovery  of  lost  data*  Programs  and 
procedures  are  widely  publicized  as  to  their 
monitoring  and  switching  capabilities.  The 
topic  of  disaster  management,  however,  goes 
far  beyond  those  measures.  They  are,  of 
course,  important  and  crucial  concerns.  Yet, 
a  false  sense  of  security  may  render  the  most 
elaborate  plans  worthless  if  the  recovery 
process  ignores  the  ability  to  return  to 
normalcy.  This  ability  must  address  the 
issues  of  confidence,  reliability,  integrity, 
availability,  and  the  resumption  of  business 
functions  with  continuity  of  operations. 

Certain  industrial,  commercial,  and  service 
organizations  may  rely  upon  a  totally  auto¬ 
mated  system.  These  entities  usually  include 
those  activities  which  offer  the  consumer  a 
limited  choice  of  vendor.  Federal  agencies, 
major  municipalities,  utilities,  securities, 
monetary  services,  military,  and  public 
safety  agencies  quickly  come  to  mind. 
Smaller  organizations,  but  still  including 
the  major  industries  of  any  given  area,  are 
much  more  affected  by  geographic  locations  of 
competitors.  it  is  all  of  these  groups  to 
which  this  paper  is  ded leaned. 

The  "cook  book"  approach  has  been  used  ir.  an 
effort  to  provide  a  kind  of  checklist  of 
things  to  do;  and,  one  should  not  ignore  the 
many  tasks  involved  in  contingency  planning. 
The  position  here  is  not  that  such  approaches 
are  wrong  nor  incomplete  nor  inappropriate; 
they  serve  a  very  vital  purpose.  In  the 
government,  OMB  Circular  A-130  and  the 
National  Bureau  of  standards'  special  pub¬ 
lication  NBS  500-134,  "A  Guide  on  Selecting 
ADP  Back-up  Processing  Alternatives"  are  most 
helpful.  OMB  Circular  A-130  establishes 
guidelines  and  authority  while  NBS  500-133 
offers  a  useful  contingency  planning  check¬ 
list.  However,  planning  for  contingencies  is 
but  the  first  step.  The  return  to  normalcy 
is,  in  our  opinion,  a  more  global  and  more 
critical  issue.  Protecting  "our"  data  is  im¬ 
portant,  but  conveying  to  users  the  feeling 
of  confidence  that  our  contingency  strategy 
provides  continuous  business  functions  is  of 
a  greater  magnitude. 

To  create  such  a  mechanism  requires  a  commit¬ 
ment  to  the  notion  that  contingency  planning 
is  both  an  attitude  and  a  process;  each  re¬ 
quiring  flexibility  of  thought,  firmness  of 
procedure,  and  commitment  of  resources.  How¬ 
ever  difficult  it  may  be,  there  must  be  a 
weighing  of  the  cost  of  contingency  planning 
and  processing  against  the  cost  of  not  doing 
business.  Mow  long  can  a  business  function 
be  suspended  before  the  business  will  fail  in 
its  attempt  to  return  to  normalcy?  Because 
contingency  processing  is  not  an  inexpensive 
activity,  it  may  well  be  that  it  is  not  for 
everyone.  Hence,  the  most  major  decision  of 
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all:  How  much  is  it  worth  to  be  able  to  re¬ 

store  the  information  processing  capabilities? 

Too  often  information  processing  is  thought 
of  only  in  terms  of  computer  activities. 
Regardless  of  the  method  of  processing  data 
the  adage  of  GIGO  remains  true.  Providing 
for  the  gathering  of  data  at  the  lowest  level 
and  the  distribution  of  results  at  that  same 
level  is  the  test  which  must  not  be  failed. 

Alternate  procedures  for  both  of  these  pro¬ 
cesses  with  a  realistic  audit  trail  rests  at 
the  heart  of  any  contingency  plan. 
Major  management  decisions  must  bo  made  at 
the  highest  level.  The  degree  of  involvement 
and  commitment  are  the  highly  visible  signs 
of  the  extent  to  which  management  truly 
wishes  to  secure  itself  against  the  hazards 
of  modern  times.  The  relatively  simple 
issues  of  yesterday  such  as  the  disgruntled 
employee  or  the  interruption  of  power  sources 
remain  as  day-to-day  concerns ,  but  new  and 
more  devastating  evils  must  be  dealt  with. 
Such  evils  include  but  are  not  limited  to 
terrorism,  nuclear  damage,  and  environmental 
deterioration.  Preoccupation  with  backup 
tapes  and  mainframes  is  being  replaced  by 
such  concerns  as  who  is  left  to  operate  that 
standby  equipment.,  how  are  those  people 
transported  to  that  backup  site,  and  by  what 
means  do  our  clients  interact  within  a  sot¬ 
ting  new  to  them;  and  perhaps  new  to  us.  The 
"hot-site"  concept  has  introduced  still  a  now 
dimension  to  the  art  of  "being  ready."  It 
gains  credence  only  in  the  context  of  a 
return  to  normalcy.  Critical  transaction- 
based  functions  ordinarily  require  immed¬ 
iate  resumption  to  prevent  serious  business 
damage . 

The  position  taken  in  this  paper  suggests 
that  new  strategics  are  required  and  that 
those  new  strategies  involve  a  commitment  of 
the  highest  steps  of  the  management  ladder. 
They  require  constant  modification  which 
implies  extensive  educational  activities. 
They  mandate  a  communication  process  with 
clients  which  instills  confidence  that  we 
will  continue  to  serve  with  no  loss  of  integ¬ 
rity,  that  we  will  maintain  a  degree  of  reli¬ 
ability  which  can  and  will  surpass  that  of 
our  competitors,  and  that  the  availability  of 
our  support  or  backup  procedures  is  both 
immediate  and  continuous  to  the  extent 
necessary . 

How  are  these  strategies  addressed?  Pimply 
put,  they  are  addressed  and  effectively  dealt 
with  through  the  concept  categorized  as  the 
Return  to  normalcy.  This  concept  does  not 
substitute  for  well  written  programs,  docu¬ 
mentation,  or  procedures.  Neither  does  it 
substitute  for  the  many  commercially  avail¬ 
able  techniques  which  preserve  already 
gathered  data.  The  value  of  the  Return  to 
Normalcy  concept  rests  in  its  ability  to 


involve,  stimulate,  and  support.  It  embraces 
the  loll  owing  concepts: 

1.  continued  senior  management  support 
for  contingency  as  a  process. 

2.  or  close  to  simulated  disaster  as 
is  feasible  in  testing  contingency. 

3.  the  ramifications  of  a  fully  imple¬ 
mented  "hot  contingency  site," 

4.  the  cost-effective  use  oi  fully 
implemented  back-up  sites. 

5.  issues  in  providing  contingency 
backup  for  multiple  sites. 

6.  the  cost  of  quality  contingency 
hackup  services. 

7.  returning  to  "business  ar  usual." 

Contingency  preparedness,  therefore,  is  not 
just  a  program;  it  is  a  process  which  roi.iujas 
effective  only  when  it  is  reflective  of  a 
management  attitude. 

To  deal  with  the  concept  of  senior  management 
support  requires  a  bold  commitment  of  re¬ 
sources  and  a  willingness  to  defend  that 
position.  It  is  difficult  to  prescribe  ex¬ 
actly  what  method  of  information  processing 
backup  is  best.  This  is  a  relatively  new 
field"  although  the  notions  of  stuffing  the 
mattress.-  filling  the  sate  deposit  box,  and 
burying  the  secret  treasure  map  have  been 
with  us  a  long  time.  What  makes  today  dif¬ 
ferent  is  the  need  or  desire  to  maintain 
continuous  processing  regardless  of  the 
operating  environment. 

how  best  to  do  this  involves  extensive  study 
of  the  kinds  of  mishaps  which  might  befall  an 
organization  and  the  measures  which  would 
allow  uninterrupted  service  to  customers  or 
clients.  Fundamental  to  those  studies  are 
the  measurement  of  tolerable  down  time,  delay 
in  converting  to  the  selected  alternative, 
start-up  time  required  to  bring  facilities  up 
to  full  performance  capabilities,  reconcili¬ 
ation  of  data  and/or  transactions,  and  the 
conversion  back  to  "business  as  usual". 

A  study  of  this  magnitude  is,  in  itself,  time 
consuming  and  expensive.  Further  it  requires 
parameters  which  delimit  those  alternatives 
to  acceptable  cost  considerations.  Because 
such  a  study  adds  nothing  to  the  product  or 
service  and  because  it  includes  consideration 
of  events  which  may  be  considered  ludicrous 
by  soma,  senior  management  stamina  is  vital. 

Even  after  the  conclusion  of  the  study  senior 
managements'  role  continues.  A  further  deci¬ 
sion  must  be  made:  is  the  recommendation 
acceptable  or,  if  alternatives  are  presented, 
is  one  acceptable?  If  not,  further  study  is 
the  1  ikely  next  step.  And  so  the  process 
continues.  At  each  crossroad  senior  manage¬ 
ment  must  again  test  his  or  her  degree  of 
conviction  that  the  cost  of  contingency  pre¬ 
paredness  is  less  than  the  cost  of  not  doing 
business . 


Among  the  possible  alternatives,  and  a  biased 
choice  on  the  part  of  the  authors,  is  the  es¬ 
tablishment  of  a  "hot  site."  By  definition, 
a  “hot  site"  is  a  staffed  facility  capable  of 
continuing  information  processing  operations. 
However,  hot  is  a  relative  term  and  there  are 
varying  degrees  of  staffing. 

The  many  possibilities  including  degree  of 
readiness  and  staffing  make  this  a  particu¬ 
larly  difficult  issue  with  which  to  deal. 
Ideally,  paralleling  facilities  and  personnel 
would  ofler  maximum  coverage  and  security. 
However,  even  under  these  conditions  consid¬ 
eration  is  usually  given  only  to  computer 
equipment  and  related  personnel.  Issues  of 
comparable  importance  which  are  often  over¬ 
looked  are  input  procedures  including  commu¬ 
nication  links  to  the  client,  control  tech¬ 
niques,  storage,  forms,  client  service,  and 
audit  trail. 

Perhaps  the  biggest  problem  vMt-'n  the  fully 
equipped  and  staffed  "hot  site"  is  not  the 
cost,  as  one  night  think,  but  rather  the  in¬ 
ability  to  keep  talented  employees  honed  to 
maximum  efficiency.  High  turnover  coupled 
with  excessive  training  time  and  costs  con¬ 
tribute  to  an  expensive  and  inefficient 
operation. 

A  "hot  site"  with  duplicate  hardware  but  min¬ 
imal  staff  provides  a  better  solution.  The 
limited  staff  con  be  challenged  by  performing 
developmental  and  testing  functions.  Train¬ 
ing  remains  an  important  feature  but  it  is 
more  easily  accomplished.  However,  a  limited 
staff  is  unable  to  maintain  full  scale  opera¬ 
tions.  To  overcome  this  shortcoming,  contin¬ 
gency  teams  can  be  employed.  Such  teams  con¬ 
sist  of  selected  key  individuals,  trained  in 
specific  aspects  of  operations,  and  who  are 
regularly  employed  at  remote  sites.  In  the 
event  of  a  catastrophe,  the  team  members 
repoct  to  the  "hot  site"  to  lend  support  to 
the  "hot  site"  staff. 

An  approach  of  this  nature  overcomes  one  of 
the  major  problems  in  disaster  recovery: 
getting  required  personnel  to  the  contingency 
site,  it  cannot  be  assumed  that  employees  at 
a  damaged  or  destroyed  location  can  be  relo¬ 
cated.  They  may  be  injured  or  may  not  have 
survived  the  incident.  Travel  may  be  inter¬ 
rupted  or  totally  suspended.  Further,  when 
the  chips  a'e  down,  employees  may  not  be 
willing  to  leave  families  or  may  be  too  dis¬ 
traught  to  be  concerned  with  such  things  as 
contingency  operations. 

A  well  conceived  "hot  site"  must  also  include 
current  backup  data,  supplies,  and  an  elabo¬ 
rate  set  of  procedures.  While  each  of  these 
is  important,  procedures  are  the  most  criti¬ 
cal.  They  arc  also  the  most  difficult  to 
maintain  current.  Not  only  must  they  de¬ 
scribe  what  must  be  done,  when,  how,  and  by 
whom,  they  must  also  describe  and  prescribe 
under  what  circumstances  a  contingency  plan 
should  be  activated  and  by  whom?.  And, 
further,  they  must  blueprint  how  the  organ¬ 
ization  repositions  itself  to  a  state  called 
normalcy  which  may,  in  some  cases,  be  a  new 
or  improved  environment. 
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Despite  the  completeness  of  outfitting  the 
contingency  site,  the  staff  training,  and  the 
detail  of  the  procedures,  no  disaster  re¬ 
covery  plan  can  be  considered  remotely  secure 
without  repeated  testing.  Unfortunately, 
most  tests  are  limited  to  performing  parallel 
operations  under  rather  ideal  conditions. 
Although  it,  may  appear  to  be  courting 
self-imposed  disaster,  a  part  of  the  testing 
progr&ir.  must  include  a  complete  catastrophe- 
simulated  situation.  An  unannounced  date 
should  be  selected  without  regard  to 
vacations,  peak  periods,  or  system 
conversions.  This  truly  is  a  test  of  senior 
management  conviction. 

Carefully  avoided,  thus  far,  has  been  any 
approximation  of  cost  and  it  will  continue  to 
be  avoided  since  the  number  of  variables  is 
significant.  Worthy  of  exploration  is  the 
use  of  the  contingency  facility  to  serve 
several  users.  Two  points  are  obvious.  One 
is  that  costs  could  be  significantly  reduced 
if  even  a  few  users  are  involved.  The  other 
is  the  dilemma  if  two  or  more  users  are 
struck  at  nearly  the  same  time. 

These  are  not  the  only  considerations,  how¬ 
ever.  Closely  following  the  two  major  pro¬ 
blems  are  issues  such  as  training  and  sup¬ 
plies.  While  thire  n.ay  be  certain  simi¬ 
larities  in  compute.,  operations,  the  many 
other  tasks  necessa..  y  to  make  an  organization 
functic  i  present  an  enormous  training  prob¬ 
lem.  Consider,  if  you  will,  the  variations 
in  order  entry  applications.  These  points 
seem  to  lend  added  support  to  the  skeletal 
"hot  cite"  supplemented  by  contingency  teams. 

Certain  cautions  must  bo  observed.  A  shared 
site  cannot  support  two  or  pore  users  from 
the  same  geographic  area.  neither  can  it 
reasonably  support  multiple  users  with  heavy 
demands  for  testing.  Depending  upon  the  sup¬ 
porting  functions  and  the  degree  of  activity 
between  user  and  client,  the  site  management 
tasks  and  responsibilities  multiply  dramati¬ 
cally. 

Keep  in  mind  that  the  scenario  prompting 
these  comments  covers  more  than  a  more  local 
fire  or  flood,  it  is  possible  that  there  is 
no  remaining  staff  to  reinforce  the  contin¬ 
gency  site.  It  is  possible  that  radiation  or 
a  poisonous  cloud  has  isolated  the  central 
site.  It  is  possible  that  the  target  loco 
tion  just  does  not  exist  any  longer. 

What  kind  of  person  must  be  found  to  assure 
that  operations  can  continue?  Many  adjec¬ 
tives  might  be  used;  intelligent,  adaptable, 
fearless,  patient,  conscientious,  loyal,  and 
more.  The  obvious  qualifications  of  loyalty 
and  honesty  go  without  saying.  The  security 
of  any  site  is  important  and  the  "hot  site" 
is  no  exception.  However,  there  are  some 
unique  circumstances.  If  we  assume  that  the 
"hot  site"  is  not  a  commercial  site  but  one 
under  the  control  of  the  principal  then  it  is 
likely  there  is  little,  if  any,  actual  pro¬ 
duction  taking  place.  If  there  were,  of 
course,  it  is  unlikely  the  description  "hot 
site"  would  be  applicable.  This  lack  of  pro¬ 
duction  has  a  severe  psycholog.’ cal  effect  on 


"hot  site"  personnel.  The  pressure  of  daily 
deadlines  is  absent  and  so  is  a  normal  rou¬ 
tine.  Hence,  personnel  must  be  highly  moti¬ 
vated  so  as  to  direct  their  energies  toward 
constructive  activities  such  as  testing 
and  training.  These  are  key  to  providing 
a  high  level  of  operational  expertise. 
The  ability  to  function  as  a  cohesive  team 
suggests  the  need  for  a  selective  recruit¬ 
ment  and  dynamic  development  process. 

Most  of  what  has  just  been  said  has  been 
directed  toward  the  Contingency  Center 
Specialist  (Computer  Operator).  There 
are  many  other  peisons  involved  when  dealing 
with  the  "hot  site."  Programmers  face  simi¬ 
lar  problems,  but  face  the  awkward  situation 
of  having  to  conform  to  objectives  anu  speci¬ 
fications  developed  at  another  location.  This 
lends  some  support  to  the  notion  of  using  the 
"hot  sice"  as  a  developmental  center  for  ex¬ 
perimenting  with  new  software  or  testing  pro¬ 
posed  procedures. 

Probably  the  most  difficult  group  of  employ¬ 
ees  to  adequately  deal  with  are  those  per¬ 
forming  the  mundane  and  routine  operations. 
Clerks,  data  entry  and  communications  opera¬ 
tors,  and  like  positions  arc  difficult  to 
keep  occupied  except  under  production  or¬ 
iented  conditions.  No  disrespect  is  intended 
sinuc  many,  or  perhaps  all,  may  be  of  superior 
ability,  nut  the  opportunities  for  develop¬ 
ment  and  growth  in  such  areas  aro  relatively 
few.  Somehow,  a  challenging  educational  pro¬ 
gram  must  be  integrated  into  the  "hot  site" 
environment  and  it.  must  be  both  interesting 
to  the  employee  and  beneficial  to  the  employ¬ 
er.  forhaos  the  idea  of  an  organizational 
training  center  utilizing  the  many  re¬ 
sources  of  the  "hot-site"  is  a  concept  worth 
exploring.  Keep  in  mind  we  are  continually 
referring  to  the  ideal  "hot  site"  which 
represents  a  duplicate  of  the  site  being 
backed  up.  Also  keep  in  mind  that  the 
position  taken  here  is  that  merely  backing 
up  the  computer  capabilities  does’ not  ensure 
that  all  of  the  usual  necessary  tasks  and 
procedures  which  come  before  and  after 
computer  processing  will  also  bo  backed  up. 

The  frequent  assumption  is  that  simply 
telling  people  to  report  to  a  different 
location  using  different  machines  will  allow 
for  continuous  operations.  This  assumption 
is  a  luxurious  approach  to  an  unrealistic 
solution.  Although  statistics  are  not 

available,  it  is  reasonable  to  assume 

that  the  probability  is  less  than  slight  such 
total  devastation  would  occur  so  as  to 
require  complete  backup.  But  that  is  pre¬ 
cisely  the  point;  modern  technology  has  pro¬ 
vided  the  opportunity  to  render  entire  com¬ 
munities  decimated  and  useless. 

To  this  point  it  would  appear  that  we  are 
building  to  a  crescendo  which  suggests  that 
there  really  is  no  such  thing  as  normalcy; 
that  the  potential  proolems  are  so  great  that 
no  solution  can  exist.  To  remain  competi¬ 
tive,  business  and  indt jtry  must  continue  to 
strive  for  that  better  mousetrap  which,  in¬ 
cidentally,  must  cost  less  than  those  of  the 
competitors.  Can  these  two  objectives  bo 
compatible  within  the  context  of  allowing  for 
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contingency  processing?  This  reinforces  the 
belief  that  senior  management  must  seriously 
and  carefully  weigh  tlic  cost  of  not  doing 
business. 

For  governmental  agencies  the  answer  may  be 
somewhat  easier.  The  profit  motive  is  re¬ 
moved.  The  public  good  demands  a  kind  of 
protection  that  warrants  such  expensive 
assurance.  Major  agencies  such  as  tine 
Department  of  Defense,  Department  of  State, 
Federal  Reserve,  Internal  Revenue  Service  and 
Social  Security  are  illustrations  of  those 
entities  which  absolutely  must  have  such 
security.  State  governments  and  major  cities 
such  as  new  York,  Lon  Angeles,  and  Chicago 
would  appear  as  likely  candidates.  F-ut  what 
of  smaller  municipalities?  Yihat  ripple  ef¬ 
fects  stemming  from  a  disruption  of  major 
local  governments  which  depend  heavily  on 
automated  facilities  would  influence  govern¬ 
mental  functioning  at  higher  levels?  As  ex¬ 
amples,  consider  ‘  he  impact  of  the  loss  of 
services  nrovidod  Daue  County,  Florida, 
and  Fairfax,  Virginia.  With  standardized  re¬ 
cording  and  reporting  techniques,  regional¬ 
ized  "not  sites"  with  contingency  teams  or 
reserve  forces  perhaps  the  degree  of  chaos 
could  be  s  ignif icantly  reduced. 

Let's  nov;  define  that  normalcy  which  has  been 
the  center  of  attention  throughout  this  pre¬ 
sentation.  In  most  cases  it  would  Le  defined 
as  an  environment  vhicn  is  familiar  and  ac¬ 
complishes  the  original  objectives  in  an 
equally  efficient  manner.  Unfortunately, 
that  definition  may  he  oversimplified. 

A  familiar  environment  is  essential;  but 
familiar  to  whom?  Certainly  the  employees 
must  lie  able  to  consider  the  equipment  and 
procedures  familiar.  This  implies  computers, 
office  equipment ,  communion! ion  equipment, 
and.  supplies  (particularly  forms;.  But 
clients*  or  customers  must  also  find  them¬ 
selves  in  familiar  territory.  In  many  crit¬ 
ical  transaction-oriented  processes,  the  user 
expects  (and  nay  require)  100  percent  avail¬ 
ability  with  no  recognizable  change  in 
functionality.  They  must  know  how  to  com¬ 
municate  and  must  be  made  aware  of  any 
changes  in  the  usual  procedures .  A  por¬ 
tion  of  the  problem  is  that  too  full  a  dis¬ 
closure  of  the  contingency  process  compro¬ 
mise;  its  security  which  is  part  of  the 
reason  tor  its  existence. 

Of  major  importance  is  the  people.  If  a  new 
staff  was  to  be  created,  woul  the  original 
employee:-,  still  be  available?  If  a  new  site 
in* created,  especially  at  a  distant  location, 
current  personnel  be  interested  in  relocating? 
If  a  contingency  team  has  been  used,  wauls 
they  want  to  return  to  their  home  site? 

There  are  no  standard  answers  for  these  ques¬ 
tions,  However,  one  point  is  clear;  the 
people  problem  is  significant  and  those  ex¬ 
pected  to  play  a  cole  in  contingency  process¬ 
ing  must  be  informed  and  reminded  of  the  de¬ 
mands  which  may  be  made  of  them. 

It  is  worth  mentioning  one  more  time  that  the 
crucial  issue  involves  the  lower  level  cler¬ 
ical  positions;  the  mail  distribution  clerks. 


the  switchboard  operators,  file  clerks,  and 
supplies  inventory  clerk.  These  are  often 
positions  which  do  not  have  their  tasks  spe¬ 
cifically  defined  or  who  have  modified  theic 
job  descriptions  on  their  own  to  more  effec¬ 
tively  deal  with  their  day-to-day  operations, 
These  highly  important  people  who  are  fre¬ 
quently  at  tne  lower  end  of  the  pay  scale  arc 
the  Rodney  Dangerf ielao  of  contingency  plan¬ 
ning.  All  too  often  they  get  no  respect. 

Returning  to  normalcy  does  not  necessarily 
mean  relocating  back  to  the  original  site. 
One  reason  is  that  the  site  may  no  longer 
exist.  A  second  reason  is  that  the  original 
location  may  no  longer  be  inhabitable.  If 
originally  located  near  major  clients  or  cus¬ 
tomers,  they  too  may  no  longer  exist.  Hence, 
there  may  be  no  real  incentive  to  return.  Cut 
senior  management  must  make  this  decision. 

In  any  event,  the  "hot  site"  may  not  bo  the 
place  in  which  to  remain.  It  may  be  too  small 
for  full-scale  operations  in  an  on-going 
mode.  Rven  if  it  is  adequate,  attention  must 
now  be  given  to  a  new  back-up  location.  And 
the  cycle  begins  to  repeat  itself. 

Can  an  organization  return  to  normalcy?  At 
this  writing  an  answer  does  not  appear  to  be 
immediately  forthcoming.  The  number  of  var¬ 
iables  seem  overwhelming.  The  extent  and 
type  of  disaster;  the  attitudes  of  individu¬ 
als;  the  availability  of  replacement  person¬ 
nel;  the  success  of  the  contingency  plan;  and 
the  availability  of  resources  to  permit  a 
recovery  all  contribute  to  the  dilemma. 

Some  aspects  of  contingency  planning  do  hold 
up  regardless  of  the  disaster  or. countered. 
First,  the  most  feasible  kinds  of  operations 
to  warrant  consideration  are  those  which  deal 
with  recordkeeping  activities.  Governmental 
entities,  insurance  companies,  monetary  and 
investment  firms,  and  organizations  selling 
services  seen  to  be  the  mrst  likely  candi¬ 
dates  . 

Second,  providing  facilities  and  staff  is 
expensive.  Only  those  organizations  with 
large  financial  resources  can  accommodate  the 
financial  roguirenenos.  When  on  organization 
exists  in  the  profit-making  arena,  the  less 
conservative  competitor  who  elects  to  risk  it 
may,  in  fact,  drive  out  (or  price  out)  its 
non-r isktaking  counterpar t . 

Governments  with  the  ability  to  acquire  rev¬ 
enue  through  increased  taxer;  may  be  among  the 
few  ’.v.io  can  arford  this  kind  of  protection. 
Even  in  this  cast.,  smaller  governments  simply 
may  not  be  able  to  bear  the  pressures. 

This  is  not  to  say  no  effort  should  ba  made, 
especially  in  the  private  sector,  to  safe¬ 
guard  the  ability  to  maintain  operations, 
i'hat  is  being  said  is  that  there  are  limits 
beyond  which  the  cost  of  not  doing  business 
may,,  in  fact,  be  loss  than  those  of  continu¬ 
ing  business.  This  truly  is  a  point  on  the 
contingency  scale  which  tests  the  entrepre¬ 
neurial  spirit  of  every  organization, 

A  third  point  which  is  clear  is  that  contin- 
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gcncy  planning  is  not  an  activity  to  bo  taken 
lightly.  There  is  probably  cone  degree  of 
contingency  preparedness  appropriate  for 
every  organisation  regardless  of  sire. 
Clearly,  the  larger  organization  has  wore 
resources  and  more  to  lose.  poor  or  inade¬ 
quate  planning  equates  to  no  planning  since 
it  is  ineffective  and  may,  in  fact,  result  in 
greater  costs. 

To  combat  this  pi  colon  it  is  essential  that 
the  contingency  planning  team  be  composed  of 
the  most  qualified  individuals.  The  limits 
of  their  study  and  their  recommendations  must 
be  clearly  defined  by  senior  management. 
Their  advice  and  proposals  should  be  careful¬ 
ly  considered.  Their  authority  to  initiate 
action  must  also  be  well  defined.  Too  liberal 
an  approach  may  be  too  expensive  to  implement 
and  too  restrictive  an  approach  nay  generate 
intolerable  frustration. 

Fourth,  a  plan  which  provides  solely  for  the 
security  of  commuter  operatic  ns  is  unrealis¬ 
tic.  it  is  window  dressing  designed  to  give 
the  appearance  of  security  in  its  shallowest 
form.  The  same  may  be  said  of  a  plan  which 
addresses  only  the  hardware  (and  son.warc)  of 
a  computer  system.  Staffing  concerns  in  noth 
the  computer  and  non-computer  functions  in¬ 
crease  in  complexity  in  a  direct  relationship 
with  the  magnitude  of  the  disaster.  Providing 
for  business  function  personnel  wherever  they 
may  be  located  is  equally  important.  Further, 
contingency  planning  extends  beyond  a  Just- 
covercd  manual.  To  serve  its  purpose  it  must 
be  reviewed  and  regenerated  at  a  pace  at 
least  equal  to  the  growth  of  the  organiza¬ 
tion  it  is  expected  to  serve. 

Fifth,  in  instances  where  quick  conversion 
and  near  full-scale  operations  are  required, 
a  "hot  cite"  is  the  safest  choice,  however, 
the  degree  of  staffing  has  a  major  influence 
on  the  sice's  operation.  Full  staffing  is 
expensive  and  inefficient  in  personnel  usage, 
minimal  staffing  cannot  support  contingency 
operations.  Hence,  a  contingency  team  or 
reserve  force  is  an  acccptaulo  compromise, 
both  in  providing  automation  capabilities 
as  well  as  attending  to  the  humanistic 
capabilities;  i.a.,  the  business  function, 
interim  activities  to  maintain  skills  and 
morale  may  include  application  testing, 
documentation,  and  program  development. 

Lastly,  none  of  the  advantages  of  contingency 
processing  can  be  realized  without  a  con¬ 
tinuous  and  active  commitment  on  the  part 
of  senior  management  which  may  possibly 
surpass  all  prior  requirements.  Beyond  this 
commitment  is  also  an  enormous  degree  of 
involvement  to  weigh  alternatives  and 
determine  that  point  at  which  the  cost  of 
contingency  exceeds  the  cost  of  not  doing 
business.  The  contingency  process;  plan¬ 
ning,  testing  and  training,  must  be  dynamic 
in  that  it  remains  effective  only  to  the 
degree  to  which  it  matches  the  changing 
business  environment. 

Can  an  organization  return  to  normalcy?  The 
authors'  opinion  is  that  the  extent  of  the 
contingency  will  determine  how  long  a  return 


will  take  if  such  a  return  is,  in  fact,  pos¬ 
sible  at  all.  Certainly  without  a  contingency 
plan  no  return  can  be  anticipated.  The  nature 
of  conceivable  disasters  in  today's  '/or lu 
suggest  that  innovative  approaches  arc  called 
for.  Cooperative  ventures,  "hot  sites",  con¬ 
tingency  teams,  and  standardized  procedures 
add  to  the  viability  of  contingency  planning. 

A  return  to  normalcy  (for  all  out  the  most 
farsighted,  creative,  daring  and  resourceful) 
s corns  to  depend  largely  on  the  nature  of 
the  disaster,  and  the  contingency  threshold; 
\;here  tiic  cost  o'  recovery  meacs  the  cost  of 
not  doing  business,  or  providing  vital  puolic 
service. 
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Abstract 

This  paper  presents  an  overview  of  National 
Telecommunications  and  Automated  Information 
Systems  Security  Advisory  Memorandum 
(NTISSAM)  C0MPUSEC/1-87,  Advisory  Memorandum 
on_ Office  Automation  Security,  which  was 
issued  in  January  1987.  This  guideline  is 
divided  into  four  parte.  Part  I  is  the 
introduction  and  Statement  of  the  Problem, 
part  II  consists  of  guidance  to  the  users  of 
OA  Systems,  Part  III  is  guidance  to  the  ADP 
system  Security  Officer  responsible  for  oa 
systems,  and  Part  IV  provides  guidance  to 
Procurement  Officers  and  others  responsible 
for  the  procurement,  disposal,  and  management 
of  OA  Systems  and  their  associated  magnetic 
media.  In  addition,  there  is  an  Appendix 
that  addresses  labeling  of  OA  Systems  and 

magnetic  media,  A  distinction  i“  made 

between  OA  systems  with  fixed  media  and  those 
with  only  removable  media.  Fixed  media  are 
defined  as  those  that  are  not  meant  to  be 
routinely  removed  from  the  system  by  a  user; 
all  other  media  are  considered  to  be 
removable.  The  guideline  addresses 

responsibilities  of  system  users,  of  the  OA 
System's  security  officer,  and  of  the 
organization  that  owns  the  system. 
Distinction  is  made  between  stand-alone  OA 
systems  (those  physically  and  electrically 
isolated  from  other  OA  systems)  and  connected 
OA  Systems  (all  others) .  Guidance  is 
provided  to  the  user  for  the  secure  operation 
of  stand-alone  systems,  of  connected  systems 
used  as  terminals  to  mainframe  computer 
systems,  and  of  connected  systems  used  as 
hosts  on  a  IAN.  An  overview  of  threats, 
vulnerabilities,  and  controls  is  provided. 
While  the  Advisory  Memorandum  addresses 
issues  in  the  areas  of  physical,  personnel, 
emanations,  communications,  hardware/ 
software,  and  procedural  security,  this  paper 
concentrates  on  hardwaie/software  security. 

introduction 

On  December  5,  1986,  the  Subcommittee  on 

Automated  Information  Systems  Security 


(SAISS)  of  th8  National  Telecommunications 
and  Information  Systems  Security  (NT1SS) 
approved  the  publication  of  Advisory 
Memorandum  on  Office  Automation .. Security  as 
an  NTISSAM  (NTISS  Advisory  Memorandum) .  In 
January  198  7,  NTISSAM  COMPUSEC/.1-87  was 
signed  by  Lieutenant  General  Odom  in  his 
capac ' ty  as  the  National  Manager  for 
Telecommunications  and  Information  Systems 
Security.  The  purpose  of  this  paper  is  to 
provide  an  overview  of  that  document. 

History  of  the  Document 

The  members  of  SAISS  Working  Group  #3,  which 
is  responsible  for  developing  computer 
security  guidelines,  believed  that  guidance 
was  needed  in  the  area  of  Office  Automation 
Security.  The  National  Computer  Security 
Center,  which  was  alreaay  working  on  an  OA 
eacurity  guideline,  was  tasked  with  drafting 
a  guideline  that  could  be  used  by  all  Federal 
Government  employees  and  contractors  using  OA 
Systems  to  process  classified  or  sensitive, 
but  unclassified,  information.  The  working 
group  provided  review  and  input  to  the 
process  at  each  step,  from  the  preliminary 
outline  to  the  final  draft.  When  WG3  was 
satisfied  with  the  draft  guideline,  it  was 
sent  to  the  members  and  observers  of  the 
SAISS  and  the  Subcommittee  on 
Telecommunications  Security  (STS)  for  their 
review.  After  several  iterations  of  this 
process,  the  guideline  was  approved. 

Structure  of  the  Document 

Advisory  Memorandum  on  Office  Automation 
security .  henceforth  referred  to  as  "the 
Guideline",  is  divided  into  four  parts.  Part 
I  is  the  Introduction  and  Statement  of  the 
Problem.  Part  II  provides  guidance  to  the 
users  of  OA  Systems.  Part  III  is  guidance  to 
the  ADP  SyEtem  Security  Officer  responsible 
for  OA  Systems,  and  Part  iv  provides  guidance 
to  Procurement  Officers  and  others 
responsible  for  the  procurement,  management, 
and/or  disposal  of  OA  Systems  and  their 
associated  magnetic  media. 
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the  system  and  its  storage  media. 


These  four  parts  are  subdivided  Into  ten 
chapters  that,  when  taken  together,  address 
ail  of  the  major  security  issues  associated 
with  oa  systems. 

Additionally/  the  document  provides  an 
Appendix  that  addresses  labeling  of  OA 
Systems  and  magnetic  media,  and  a  glossary  of 
terms  used  in  the  Guideline. 

The  purpose  of  this  paper  is  to  discuss  each 
section  of  tho  Guideline,  and  to  describe  in 
certain  cases  why  recommendations  were  or 
were  not  made. 

Introduction  and  Overview 

To  start  with,  we  must  decide  what  is  and 
what  is  not  an  "Office  Automation  System". 
The  Guideline  defines  an  OA  System  as  "Any 
microprocessor-based  AXS  or  AIS  component 
that  is  commonly  used  in  an  office 
environment.  This  includes,  but  is  net 
limited  to.  Personal  Computers,  Word 
Processors,  printers,  and  file  servers.  It 
does  not  include  electric  typewriters, 
photocopiers,  and  facsimile  machines". [1] 
While  this  author  readily  admits  to  sometimes 
finding  it  hard  to  make  a  generic  distinction 
between  an  "electronic  typewriter"  and  a 
"word  processor" ,  it  is  thought  that  this 
definition  makes  the  distinction  clear  in 
most  cases. 

The  next  step  is  to  define  the  "oa  Security 
problem".  That  is,  what  exactly  are  we 
attempting  to  protect? 

The  answer  to  this  question  has  several 
parts.  First  of  all,  we  are  trying  to 
protect  information  from  unauthorized 
disclosure-  United  States  Government  policy 
requires  that  certain  types  of  information 
not  be  disclosed  to  anyone  unless  that  person 
has  an  appropriate  security  clearance,  and/or 
specifically  needs  the  information  to  do  his 
or  her  job. [2, 3]  Host  current  OA  systems  do 
not  provide  the  hardware/ software  security 
necessary  to  enforce  the  separation  of  usero 
and  information  within  the  system;  therefore, 
procedure,  personnel,  and  physical  security 
measures  must  bo  taken  to  prevent 
unauthorized  personnel  from  accessing  the 
system,  or  from  gaining  access  to  magnetic 
storage  media  used  in  the  system. 

Secondly,  we  are  trying  to  prevent 
unauthorized  modification  of  inform ition.  To 
do  this,  we  must  again  control  access  to  both 


Thirdly,  we  are  attempting  to  prevent 
(intentional  or  cartleus)  damage  to  tho  OA 
system  itself.  This  requires  following  a  few 
simple  rules  that  will  help  prevent  the 
system  from  being  either  stolen  or  damaged. 

Fixed  Madia  ve.  Removable  Media 

In  order  to  make  the  problem  easier  to  deal 
with,  we  make  a  distinction  between  OA 
systems  with  fixed  media  and  those  with  only 
removable  media.  Fixed  media  are  defined  as 
those  that  are  not  meant  to  be  routinely 
removed  from  the  system  by  a  user.  Examples 
of  fixed  media  are  fixed  disks  and 
nonvolatile  memory  expansion  boards. 
Examples  of  removable  media  include  floppy 
dinks,  cassette  tapes,  or  removable  hard  disk 
cartridges. 

The  type  of  media  employed  within  an  OA 
system  affects  what  can  be  done  with  that 
system.  Systems  with  only  removable  media 
can  be  used  to  process  information  of 
different  sensitivity  levels  at  different 
times  ("periods  processed,"  if  you  will). 
This  means  that  information  can  be  processed 
on  the  system  that  not  all  users  of  the 
system  have  a  clearance,  authorization,  or 
need-to-Know  for.  All  that  is  required  is 
that  the  information  be  removed  from  ths 
system  before  these  people  use  it. 

Systems  with  fixed  media  can  normally  only  be 
used  to  process  one  level  of  information, 
because  tho  information  cannot  be  removed 
from  the  system.  Therefore,  all  system  users 
must  have  a  clearance  and  authorization  for 
all  information  on  the  system. 

User  Responsibilities 

All  users  must  realize  that  they  play  a  vital 
role  in  maintaining  the  security  of  an  OA 
system.  In  fact,  the  role  played  by  users  of 
OA  systems  is  much  greater  than  that  played 
by  users  of  mainframe  systems,  because  there 
are  usually  not  as  many  "security 
professionals"  overseeing  what  is  done. 
Users  should  normally  be  responsible  for  the 
following,  as  a  minimum: 

(a)  Knowing  who  the  ADPSSO  is  for  each 
system,  and  knowing  how  '-o  contact  that 
person; 

(b)  Being  aware  of,  and  following,  all 
applicable  security  guidelines. 
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(c)  Reporting  to  a  eacurlty  officer  and 
known  ot  euepected  eacurlty  violation. 
Violations  of  particular  importance  are  those 
involving  compromise  or  modification  of 
information,  and  theft  of  property. 

(d)  Using  only  approved  software.  Software 
should  not  be  used  without  having  been  tested 
by  some  responsible  party  (such  as  a  security 
officer)  .  Under  no  conditions  should  pirated 
software  be  used. 

Operational  Seourity  for  Stand-Alone  Systems 

A  stand-alone  OA  system  is  one  that  is 
physically  and  electrically  isolated  from 
other  OA  systems.  Some  rules  to  follow  when 
using  a  stand-alone  system  with  only 
removable  media  are: 

(a)  Place  monitor  screens,  printers,  or 
other  devices  that  produce  human-readable 
output  where  they  cannot  be  seen  by  casual 
passereby. 

(b)  Do  not  leave  ar.  OA  syetem  running 
unattended  while  it  contains  information  that 
someone  with  physical  access  to  it  should  not 
see.  Especially,  do  not  leav-j  a  system 
unattsnded  while  sensitive  information  is 
displayed  or.  the  screen. 

(c)  Do  not  leave  printers  unattended  while 
sensitive  information  ie  being  printed, 
unless  the  urea  in  which  the  printer  is 
located  provides  adequate  physical  security. 

(d)  Remove  output  from  printers  at  the 
earliest  possible  time. 

(s)  Ensure  that  all  human-roadabla  outputs 
are  appropriately  marked  for  sensitivity.  If 
necessary,  the  user  should  apply  the  labels 
himself . 

(f)  Do  not  eat,  drink,  or  smoke  while  using 
an  OA  system. 

(g)  Protect  magnetic  media  from  exposure  to 
smoke,  dust,  magnetic  fields,  and  liquids. 

(h)  When  a  user  is  through  with  the  system, 
(s)he  should  remove  all  sensitive  information 
from  it.  It  is  also  advisable  to  power  the 
system  off.  This  way,  there  is  little  or  r.o 
possibility  that  the  next  user  con  gain 
access  to  information,  no  matter  who  (s)he 
is. 


(i)  At  the  end  of  a  shift  (or  workday), 
remove  all  media  from  the  system,  then 
overwrite  ths  system's  memory  with  some 
pattern  before  the  system  is  powered  off.  If 
there  is  a  key,  remove  it  and  store  it  in  a 
secure  place  until  the  next  shift  or  working 
day.  Remove  printer  ribbons  that  have  been 
used  to  print  sensitive  information,  and 
store  or  dispose  of  them. 

For  systems  with  fixed  media,  the  above  rulos 
also  apply.  The  main  thing  to  keep  in  mind 
is  that  the  sensitivity  level  of  the  system 
as  a  whole  cannot  normally  bo  lowered. 
Therefore,  users  should  never  be  allowed 
access  to  tho  system  without  clearance, 
authorization,  and  need-to-Know  for  all 
information  on  ths  system. 

Sensitive  information  can  and  should  be 
removed  from  the  system,  however.  When  a 
user  is  finished,  and  has  some  files  that 
contain  information  that  should  not  be  seen 
by  other  system  users,  these  files  should  be 
copied  to  a  volume  of  removable  media,  then 
erased  from  the  fixed  media.  (Note:  for 
most  systems,  use  of  the  "delete"  command 
will  remove  the  information  from  the  medium. 
The  locations  in  memory  must  be  explicitly 
overwritten. ) 

Operational  Security  for  Connected  Office 
Automation  systems 

A  connected  OA  System  is  one  that  is  not  a 
stand-alone.  Normally,  these  systems  are 
used  in  one  (or  both)  of  two  configurations: 
as  a  terminal  attached  to  a  mainframe,  or  as 
a  host  on  a  local  area  network  (LAN) . 

When  an  OA  System  is  used  as  a  tei'minal,  it 
can  create  security  problems  for  the  system 
it  is  attached  to.  One  of  the  more  lucrative 
attacks  is  for  a  penetrator  to  program  an  OA 
system  to  copy  any  password  that  a  user 
types.  Then,  the  penetrator  returns  later 
and  can  log  into  one  (or  more)  mainframe 
computers  as  or.e  of  his  (or  her)  innocent 
victims.  The  best  solution  to  this  attack  1b 
to  use  only  communications  software  that  has 
been  tested  and  approved  by  a  "trusted  party" 
(such  as  a  security  officer),  and  to  prevent 
unauthorized  personnel  from  accessing  the  OA 
system  at  all. 

When  an  OA  System  is  used  as  a  host  on  a  LAN, 
its  inability  to  provide  adequate 
hardware/software  protection  becomes  more 
important.  In  most  of  today's  OA  systems, 
any  information  contained  in  the  system  con 
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bo  accessed  by  anyone  who  can  access  the 
oyster..  This  includes  anyone  who  can  access 
the  OA  System  via  a  network.  How,  users  must 
be  extra  careful  not  to  leave  sensitive 
information  on  the  OA  System. 

Responsibilities  of  the  ADPSSO 

There  should  be  one  individual  responsible 
for  the  security  of  each  OA  System.  This 
individual  may  or  may  not  be  one  of  the  users 
of  the  system.  There  may  be  a  different 
ADPSSO  for  each  OA  System,  or  one  with 
jurisdiction  over  all.  Regardless,  the 
ADPSSO  should  have  the  following 
responsibilities,  as  a  minimum: 

(a)  Ensuring  that  each  OA  System  is 
certified  and  accredited.  If  required  by 
organization  policy. 

(b)  Ensuring  that  all  users  of  the  system 
are  aware  of  the  security  requirements,  and 
assuring  that  all  procedures  are  followed. 

(c)  Investigating  all  reported  or  suspected 
security  violations. 

(d)  Reporting  violations  to  appropriate 
authorities  (e.g.,  top  management,  law 
enforcement  officials,  etc,). 

(e)  Ensuring  that  the  configuration 
management  program  is  followed. 

(f)  Reviewing  the  audit  logs  (if  audit  logs 
are  used) . 

Threats,  Vulnerabilities,  and  Controls 

A  threat  is  a  person,  thing,  or  event  that 
can  exploit  a  vulnerability  of  the  system, 
such  as  a  wiretapper,  a  business  competitor, 
or  a  maintenance  person. 

A  vulnerability  is  an  area  in  which  an 
attack,  if  made,  is  likely  to  be  successful. 
Examples  of  vulnerabilities  include  lack  of 
identification  and  authentication  schemes, 
lack  of  physical  access  controls,  and  lack  or 
communications  security  controls. 

A  security  control  is  a  step  that  is  taken  in 
an  attempt  to  reduce  the  probability  of 
exploitation  of  a  vulnerability.  Examples  of 
controls  include  the  use  of  encryption,  a 
configuration  management  program,  or  a 
hordware/software  security  feature. 

There  are  many  threats  and  vulnerabilities 


associated  with  OA  Systems.  These  occur  in 
the  areas  of  physical  and  personnel  security, 
communications  security,  emanations  security, 
hardware/software  security,  and  magnetic 
remanence.  While  the  Guideline  addresses  all 
of  these  issues  to  some  degree,  we  nov 
concentrate  on  hardware/software  security. 

OA  Systems  can  be  broken  down  into  three 
categories:  single  user  systems,  shared-use 
systems,  and  multl-usar  systems.  Single  user 
Bystems  are  those  that  are  used  exclusively 
by  one  person.  Obviously,  no 
h&rdware/software  security  is  needed  for 
these  systems,  regardless  of  whether  or  not 
fixed  media  is  employed. 

Shared-use  systems  are  those  that  are  used  by 
more  than  one  person;  however,  only  one  uses 
the  system  at  a  time.  Multi-user  systems  are 
those  that  are  used  by  more  then  one  person 
at  the  eame  time.  For  ahared-use  systems,  no 
hardware/eoftware  security  io  needed  if  only 
removable  media  is  used.  However,  if  fixed 
media  is  employed,  then  either  all  users  of 
the  system  must  have  a  clearance  and  noed-to- 
know  for  all  information,  or  the  system 
should  mast  the  requirements  of  at  least 
class  Cl,  as  specified  in  the  TCSEC.  Multi¬ 
user  systems  should  mast  these  r aqui i emente , 
regardless  of  whether  or  not  they  .employ 
fixed  media. 

Currently,  there  are  a  large  number  of 
products  available  on  the  commercial  market 
that  claim  to  provide  security  for  OA 
Systems.  However,  as  of  the  time  of  this 
writing,  none  of  theBa  products  has  been 
certified  by  the  National  Computer  Security 
Center  as  meeting  even  the  claes  Cl 
requirements .  While  many  of  these  security 
products  are  useful  and  do  provide  some 
protection,  anyone  using  them  should  be 
careful  not  to  be  lulled  into  a  "false  sense 
of  security." 

There  are  several  equipment  vendors  who  are 
attempting  to  build  OA  Systems  or 
workstations  that  will  meet  specific  levels 
of  the  TCSEC.  If  these  vendors  are 
successful,  it  will  be  possible  to  control 
sharing  of  information  on  the  OA  System 
itself,  by  using  the  hardware/software 
controls  provided  by  the  OA  System.  The 
procedural  controls  needed  will  then  be  less 
severe  than  what  is  currently  required. 

Organisational  Responsibilities 

The  organiration  which  "owns"  (or  leases,  or 
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is  othcrwisu  responsible  for  the  secure 
operation  ol )  an  OA  System  has  sevoial 
responsibilities.  Those  include; 

(a)  Having  a  security  policy  that  defines, 
at  a  minimum,  what  actions  arc  permissible  on 
an  OA  System,  what  information  may  be 
processed  when  and  by  whom,  what  the 
organization  permits  regarding  the  use  of 
govsrnment-owned  OA  Systems  offsite,  the  use 
of  personally  owned  OA  Systems  to  do 
government  work,  procedures  for  maintenance 
of  OA  Systems,  and  procedures  for  the  secure 
handling,  marking,  storage,  and  disposal  of 
sensitive  information. 

(b)  Setting  up  a  training  program  to  ensure 
that  users  and  ADPsSOe  are  awaro  of  their 
responsibil it ies . 

(c)  Having  a  policy  concerning  the 
procurement  and  use  of  hardware/  software. 
This  policy  should  explicitly  address  the 
topics  of  copyrights  and  licensing 
agreements . 

(cl)  Having  a  configuration  management 
program  in  p'cce. 


Information  Systems  that,  will  be  connected  to 
the  OA  System  should  be  considered. 

Conclusion 

This  guideline  provides  an  important  first 
step  in  assuring  Offici  Automation  security 
for  the  Federal  Government  and  its 
contractors.  It  is  very  useful  by  the 
private  Bector,  also. 
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Procuring  OA  systems 


Before  an  organization  begins  to  procure  OA 
Syetems,  it  should  tako  several  steps  to 
determine  exactly  what  tfie  security  needs 
will  be  The  first  ot  tfiese  steps  ir.  a  risk 
analysis,  as  definud  in  OMB  Circular  A- 
130. [5]  In  addition,  the  following  issues 
should  be  addressed: 


(a)  If  the  OA  System  will  be  processing 
classified  information,  there  are  policy 
requirements  for  communications  security  and 
emanations  security  that  must  be  met. 

(b)  Since  an  OA  System  is  generally 
considered  to  be  a  high-dollar  asset,  it 
should  be  either  kept  in  an  area  where  it 
will  not  be  stolen,  or  it  should  be  locked  to 
a  table  or  in  a  cabinet. 

(c)  Any  nonvolatile  parts  of  the  OA  System 
should  be  identified. 

(d)  security  requirements  of  any  Automated 
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